[U-Boot] Using MinGW gcc cross-compiling host tools for Windows broken

[U-Boot] Using MinGW gcc cross-compiling host tools for Windows broken

[Bin Meng]

Hi Peter,

I noticed that you were the first one that added support to build
native Win32 tools using MinGW GCC via:

commit 2f8d396b9302eddcd8d552648e101a46b7a80acd
Author: Peter Tyser <ptyser@xes-inc.com>
Date:   Fri Mar 13 18:54:51 2009 -0500

    Add support for building native win32 tools

    Add support for compiling the host tools in the tools directory using
    the MinGW toolchain.  This produces executables which can be used on
    standard Windows computers without requiring cygwin.

    One must specify the MinGW compiler and strip utilities as if they
    were the host toolchain in order to build win32 executables, eg:

    make HOSTCC=i586-mingw32msvc-gcc HOSTSTRIP=i586-mingw32msvc-strip tools

    Signed-off-by: Peter Tyser <ptyser@xes-inc.com>

There are also several follow-up commits that fixed the build errors
from time to time:

commit 8b6a4952e6064dc558cb7d5d375990b17491f26f
Author: Vladimir Yakovlev <nagos@inbox.ru>
Date:   Sat Jul 7 10:05:06 2012 +0000

    tools: Fix mingw tools build

    mkenvimage does not build due to missed os_support.o and unsupported
    file modes S_IRGRP S_IWGRP.
    Tested with mingw 4.2.1 on ubuntu 12.04.

    Signed-off-by: Vladimir Yakovlev <nagos@inbox.ru>

commit b050c72d52c4e30d5b978ab6758f8dcdbe5c690c
Author: Mike Frysinger <vapier@gentoo.org>
Date:   Tue Apr 20 05:49:30 2010 -0400

    compiler.h: add uint typedef

    Recent crc changes started using the "uint" type in headers that are used
    on the build system.  This subsequently broke mingw targets as they do not
    provide such a type.  So add this basic typedef to compiler.h so that we
    do not have to worry about this breaking again in the future.

    Signed-off-by: Mike Frysinger <vapier@gentoo.org>

commit faf36c1437c95e4a86835633d9801c5f6396a3c7
Author: Remy Bohmer <linux@bohmer.net>
Date:   Wed Oct 28 22:13:36 2009 +0100

    Fix mingw tools build

    mkimage does not build due to missing strtok_r() and getline()
implementation

    Signed-off-by: Remy Bohmer <linux@bohmer.net>

Today I tried to build the Windows tools by following the README, and
got build errors.

$ make HOSTCC=/usr/bin/x86_64-w64-mingw32-gcc tools

note: I am running this from Linux. It's not clear to me whether we
should run this from Windows natively or cross-compile on Linux.

It seems that this MinGW Windows build has been broken for quite a long time.

Will you address this? Thanks!

Regards,
Bin

[U-Boot] Using MinGW gcc cross-compiling host tools for Windows broken

[Peter Tyser]

Hi Bin,

----- Original Message -----
> From: "Bin Meng" <bmeng.cn@gmail.com>
> To: "ptyser" <ptyser@xes-inc.com>, "Vladimir Yakovlev" <nagos@inbox.ru>, "Mike Frysinger" <vapier@gentoo.org>, "Remy
> Bohmer" <linux@bohmer.net>, "U-Boot Mailing List" <u-boot@lists.denx.de>
> Cc: "Tom Rini" <trini@konsulko.com>
> Sent: Monday, October 14, 2019 4:46:16 AM
> Subject: Using MinGW gcc cross-compiling host tools for Windows broken

> Hi Peter,
> 
> I noticed that you were the first one that added support to build
> native Win32 tools using MinGW GCC via:
> 
> commit 2f8d396b9302eddcd8d552648e101a46b7a80acd
> Author: Peter Tyser <ptyser@xes-inc.com>
> Date:   Fri Mar 13 18:54:51 2009 -0500
> 
>    Add support for building native win32 tools
> 
>    Add support for compiling the host tools in the tools directory using
>    the MinGW toolchain.  This produces executables which can be used on
>    standard Windows computers without requiring cygwin.
> 
>    One must specify the MinGW compiler and strip utilities as if they
>    were the host toolchain in order to build win32 executables, eg:
> 
>    make HOSTCC=i586-mingw32msvc-gcc HOSTSTRIP=i586-mingw32msvc-strip tools
> 
>    Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> 
> There are also several follow-up commits that fixed the build errors
> from time to time:
> 
> commit 8b6a4952e6064dc558cb7d5d375990b17491f26f
> Author: Vladimir Yakovlev <nagos@inbox.ru>
> Date:   Sat Jul 7 10:05:06 2012 +0000
> 
>    tools: Fix mingw tools build
> 
>    mkenvimage does not build due to missed os_support.o and unsupported
>    file modes S_IRGRP S_IWGRP.
>    Tested with mingw 4.2.1 on ubuntu 12.04.
> 
>    Signed-off-by: Vladimir Yakovlev <nagos@inbox.ru>
> 
> commit b050c72d52c4e30d5b978ab6758f8dcdbe5c690c
> Author: Mike Frysinger <vapier@gentoo.org>
> Date:   Tue Apr 20 05:49:30 2010 -0400
> 
>    compiler.h: add uint typedef
> 
>    Recent crc changes started using the "uint" type in headers that are used
>    on the build system.  This subsequently broke mingw targets as they do not
>    provide such a type.  So add this basic typedef to compiler.h so that we
>    do not have to worry about this breaking again in the future.
> 
>    Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> 
> commit faf36c1437c95e4a86835633d9801c5f6396a3c7
> Author: Remy Bohmer <linux@bohmer.net>
> Date:   Wed Oct 28 22:13:36 2009 +0100
> 
>    Fix mingw tools build
> 
>    mkimage does not build due to missing strtok_r() and getline()
> implementation
> 
>    Signed-off-by: Remy Bohmer <linux@bohmer.net>
> 
> Today I tried to build the Windows tools by following the README, and
> got build errors.
> 
> $ make HOSTCC=/usr/bin/x86_64-w64-mingw32-gcc tools
> 
> note: I am running this from Linux. It's not clear to me whether we
> should run this from Windows natively or cross-compile on Linux.

It was intended to be cross-compiled on a Linux box.

> It seems that this MinGW Windows build has been broken for quite a long time.
> 
> Will you address this? Thanks!

I had a quick look at getting compilation working, and my vote is to remove
support for the MinGW compilation.
- It can't be too popular since the compilation issues haven't been
flagged for a long time.

- The motivation 10 years ago was to support customers that used Windows as
their OS development environment, mostly for VxWorks.  Development under a
100% Windows environment seems a lot less common nowadays.  Virtual machines
and Windows Subsystem for Linux also make it much easier to run Linux apps
in a Windows development environment.  My company hasn't been distributing
the MinGW binary for a number of years now as a data point.

- The feature set of some of the U-Boot tools has increased quite a bit
which makes it non-trivial to support with MinGW.  For example mkimage links
with libssl and libcrypto.

I'm guessing more duct tape on the make system would be needed to get
MinGW working, and my thought is that ugliness isn't worth the benefit
anymore.

I'm happy to gin up a patch if others agree and think removing
MinGW support makes sense.

Regards,
Peter

[U-Boot] Using MinGW gcc cross-compiling host tools for Windows broken

[Bin Meng]

Hi Peter,

On Tue, Oct 15, 2019 at 10:44 AM Peter Tyser <ptyser@xes-inc.com> wrote:
>
> Hi Bin,
>
> ----- Original Message -----
> > From: "Bin Meng" <bmeng.cn@gmail.com>
> > To: "ptyser" <ptyser@xes-inc.com>, "Vladimir Yakovlev" <nagos@inbox.ru>, "Mike Frysinger" <vapier@gentoo.org>, "Remy
> > Bohmer" <linux@bohmer.net>, "U-Boot Mailing List" <u-boot@lists.denx.de>
> > Cc: "Tom Rini" <trini@konsulko.com>
> > Sent: Monday, October 14, 2019 4:46:16 AM
> > Subject: Using MinGW gcc cross-compiling host tools for Windows broken
>
> > Hi Peter,
> >
> > I noticed that you were the first one that added support to build
> > native Win32 tools using MinGW GCC via:
> >
> > commit 2f8d396b9302eddcd8d552648e101a46b7a80acd
> > Author: Peter Tyser <ptyser@xes-inc.com>
> > Date:   Fri Mar 13 18:54:51 2009 -0500
> >
> >    Add support for building native win32 tools
> >
> >    Add support for compiling the host tools in the tools directory using
> >    the MinGW toolchain.  This produces executables which can be used on
> >    standard Windows computers without requiring cygwin.
> >
> >    One must specify the MinGW compiler and strip utilities as if they
> >    were the host toolchain in order to build win32 executables, eg:
> >
> >    make HOSTCC=i586-mingw32msvc-gcc HOSTSTRIP=i586-mingw32msvc-strip tools
> >
> >    Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> >
> > There are also several follow-up commits that fixed the build errors
> > from time to time:
> >
> > commit 8b6a4952e6064dc558cb7d5d375990b17491f26f
> > Author: Vladimir Yakovlev <nagos@inbox.ru>
> > Date:   Sat Jul 7 10:05:06 2012 +0000
> >
> >    tools: Fix mingw tools build
> >
> >    mkenvimage does not build due to missed os_support.o and unsupported
> >    file modes S_IRGRP S_IWGRP.
> >    Tested with mingw 4.2.1 on ubuntu 12.04.
> >
> >    Signed-off-by: Vladimir Yakovlev <nagos@inbox.ru>
> >
> > commit b050c72d52c4e30d5b978ab6758f8dcdbe5c690c
> > Author: Mike Frysinger <vapier@gentoo.org>
> > Date:   Tue Apr 20 05:49:30 2010 -0400
> >
> >    compiler.h: add uint typedef
> >
> >    Recent crc changes started using the "uint" type in headers that are used
> >    on the build system.  This subsequently broke mingw targets as they do not
> >    provide such a type.  So add this basic typedef to compiler.h so that we
> >    do not have to worry about this breaking again in the future.
> >
> >    Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> >
> > commit faf36c1437c95e4a86835633d9801c5f6396a3c7
> > Author: Remy Bohmer <linux@bohmer.net>
> > Date:   Wed Oct 28 22:13:36 2009 +0100
> >
> >    Fix mingw tools build
> >
> >    mkimage does not build due to missing strtok_r() and getline()
> > implementation
> >
> >    Signed-off-by: Remy Bohmer <linux@bohmer.net>
> >
> > Today I tried to build the Windows tools by following the README, and
> > got build errors.
> >
> > $ make HOSTCC=/usr/bin/x86_64-w64-mingw32-gcc tools
> >
> > note: I am running this from Linux. It's not clear to me whether we
> > should run this from Windows natively or cross-compile on Linux.
>
> It was intended to be cross-compiled on a Linux box.
>
> > It seems that this MinGW Windows build has been broken for quite a long time.
> >
> > Will you address this? Thanks!
>
> I had a quick look at getting compilation working, and my vote is to remove
> support for the MinGW compilation.

Thanks for looking at this.

> - It can't be too popular since the compilation issues haven't been
> flagged for a long time.
>
> - The motivation 10 years ago was to support customers that used Windows as
> their OS development environment, mostly for VxWorks.  Development under a
> 100% Windows environment seems a lot less common nowadays.  Virtual machines
> and Windows Subsystem for Linux also make it much easier to run Linux apps
> in a Windows development environment.  My company hasn't been distributing
> the MinGW binary for a number of years now as a data point.

Ah, I was going to investigate building a complete Windows U-Boot host
tools for VxWorks as well :-)

>
> - The feature set of some of the U-Boot tools has increased quite a bit
> which makes it non-trivial to support with MinGW.  For example mkimage links
> with libssl and libcrypto.
>
> I'm guessing more duct tape on the make system would be needed to get
> MinGW working, and my thought is that ugliness isn't worth the benefit
> anymore.
>

The reason I was looking at MinGW first is because I think we can
benefit from GitLab-CI to cross-build Windows host tools for us to
make sure it won't be broken any more in the future.

> I'm happy to gin up a patch if others agree and think removing
> MinGW support makes sense.
>

I agree. Let's drop the support. I will have to seek for other solutions.

Regards,
Bin

[U-Boot] Using MinGW gcc cross-compiling host tools for Windows broken

[Vladimir Yakovlev]

I had used native mkenvimage for board deployment, but since it was
replaced by python script. We had some bugs with cross compiled tools,
which was not present in native linux tools.

Python script like this to make unique mac addresses.

ENV_SIZE = 131072
d = env_template % mac_address
d = d.replace("\n", "\0")
for i in range(ENV_SIZE - len(d) - 4 - 1):
        d += "\xff"
crc = binascii.crc32(d) % (1<<32)
f = open("out.env", "wb+")
crc_buf = struct.pack("I", crc)
f.write(crc_buf)
f.write("\x01")
f.write(d)
f.close()

вт, 15 окт. 2019 г. в 10:54, Bin Meng <bmeng.cn@gmail.com>:

> Hi Peter,
>
> On Tue, Oct 15, 2019 at 10:44 AM Peter Tyser <ptyser@xes-inc.com> wrote:
> >
> > Hi Bin,
> >
> > ----- Original Message -----
> > > From: "Bin Meng" <bmeng.cn@gmail.com>
> > > To: "ptyser" <ptyser@xes-inc.com>, "Vladimir Yakovlev" <nagos@inbox.ru>,
> "Mike Frysinger" <vapier@gentoo.org>, "Remy
> > > Bohmer" <linux@bohmer.net>, "U-Boot Mailing List" <
> u-boot at lists.denx.de>
> > > Cc: "Tom Rini" <trini@konsulko.com>
> > > Sent: Monday, October 14, 2019 4:46:16 AM
> > > Subject: Using MinGW gcc cross-compiling host tools for Windows broken
> >
> > > Hi Peter,
> > >
> > > I noticed that you were the first one that added support to build
> > > native Win32 tools using MinGW GCC via:
> > >
> > > commit 2f8d396b9302eddcd8d552648e101a46b7a80acd
> > > Author: Peter Tyser <ptyser@xes-inc.com>
> > > Date:   Fri Mar 13 18:54:51 2009 -0500
> > >
> > >    Add support for building native win32 tools
> > >
> > >    Add support for compiling the host tools in the tools directory
> using
> > >    the MinGW toolchain.  This produces executables which can be used on
> > >    standard Windows computers without requiring cygwin.
> > >
> > >    One must specify the MinGW compiler and strip utilities as if they
> > >    were the host toolchain in order to build win32 executables, eg:
> > >
> > >    make HOSTCC=i586-mingw32msvc-gcc HOSTSTRIP=i586-mingw32msvc-strip
> tools
> > >
> > >    Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> > >
> > > There are also several follow-up commits that fixed the build errors
> > > from time to time:
> > >
> > > commit 8b6a4952e6064dc558cb7d5d375990b17491f26f
> > > Author: Vladimir Yakovlev <nagos@inbox.ru>
> > > Date:   Sat Jul 7 10:05:06 2012 +0000
> > >
> > >    tools: Fix mingw tools build
> > >
> > >    mkenvimage does not build due to missed os_support.o and unsupported
> > >    file modes S_IRGRP S_IWGRP.
> > >    Tested with mingw 4.2.1 on ubuntu 12.04.
> > >
> > >    Signed-off-by: Vladimir Yakovlev <nagos@inbox.ru>
> > >
> > > commit b050c72d52c4e30d5b978ab6758f8dcdbe5c690c
> > > Author: Mike Frysinger <vapier@gentoo.org>
> > > Date:   Tue Apr 20 05:49:30 2010 -0400
> > >
> > >    compiler.h: add uint typedef
> > >
> > >    Recent crc changes started using the "uint" type in headers that
> are used
> > >    on the build system.  This subsequently broke mingw targets as they
> do not
> > >    provide such a type.  So add this basic typedef to compiler.h so
> that we
> > >    do not have to worry about this breaking again in the future.
> > >
> > >    Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> > >
> > > commit faf36c1437c95e4a86835633d9801c5f6396a3c7
> > > Author: Remy Bohmer <linux@bohmer.net>
> > > Date:   Wed Oct 28 22:13:36 2009 +0100
> > >
> > >    Fix mingw tools build
> > >
> > >    mkimage does not build due to missing strtok_r() and getline()
> > > implementation
> > >
> > >    Signed-off-by: Remy Bohmer <linux@bohmer.net>
> > >
> > > Today I tried to build the Windows tools by following the README, and
> > > got build errors.
> > >
> > > $ make HOSTCC=/usr/bin/x86_64-w64-mingw32-gcc tools
> > >
> > > note: I am running this from Linux. It's not clear to me whether we
> > > should run this from Windows natively or cross-compile on Linux.
> >
> > It was intended to be cross-compiled on a Linux box.
> >
> > > It seems that this MinGW Windows build has been broken for quite a
> long time.
> > >
> > > Will you address this? Thanks!
> >
> > I had a quick look at getting compilation working, and my vote is to
> remove
> > support for the MinGW compilation.
>
> Thanks for looking at this.
>
> > - It can't be too popular since the compilation issues haven't been
> > flagged for a long time.
> >
> > - The motivation 10 years ago was to support customers that used Windows
> as
> > their OS development environment, mostly for VxWorks.  Development under
> a
> > 100% Windows environment seems a lot less common nowadays.  Virtual
> machines
> > and Windows Subsystem for Linux also make it much easier to run Linux
> apps
> > in a Windows development environment.  My company hasn't been
> distributing
> > the MinGW binary for a number of years now as a data point.
>
> Ah, I was going to investigate building a complete Windows U-Boot host
> tools for VxWorks as well :-)
>
> >
> > - The feature set of some of the U-Boot tools has increased quite a bit
> > which makes it non-trivial to support with MinGW.  For example mkimage
> links
> > with libssl and libcrypto.
> >
> > I'm guessing more duct tape on the make system would be needed to get
> > MinGW working, and my thought is that ugliness isn't worth the benefit
> > anymore.
> >
>
> The reason I was looking at MinGW first is because I think we can
> benefit from GitLab-CI to cross-build Windows host tools for us to
> make sure it won't be broken any more in the future.
>
> > I'm happy to gin up a patch if others agree and think removing
> > MinGW support makes sense.
> >
>
> I agree. Let's drop the support. I will have to seek for other solutions.
>
> Regards,
> Bin
>