[U-Boot-Users] FYI: building u-boot image in cygwin environment fails
-----Original Message----- From: Povolotsky, Alexander Sent: Friday, July 23, 2004 8:30 AM To: 'crossgcc@sources.redhat.com'; 'wd@denx.de' Cc: linuxppc-dev@lists.linuxppc.org Subject: FYI: building u-boot image in cygwin environment fails
apovolot@USPITLAD104868 ~/U-boot/u-boot-1.1.1 $ make MPC8260ADS_config Configuring for MPC8260ADS board...
apovolot@USPITLAD104868 ~/U-boot/u-boot-1.1.1 $ make all ............... make[1]: Entering directory `/cygdrive/d/Profiles/apovolot/U-boot/u-boot-1.1.1/t ools' gcc -Wall -pedantic -D__WIN32__ -I../include -I.. -DTEXT_BASE=0xfff00000 -DUSE_H OSTCC -O -c -o img2srec.o img2srec.c In file included from img2srec.c:60: ../include/elf.h:46: warning: redefinition of `uint8_t' /usr/include/stdint.h:24: warning: `uint8_t' previously declared here ../include/elf.h:47: warning: redefinition of `uint16_t' /usr/include/stdint.h:25: warning: `uint16_t' previously declared here ../include/elf.h:48: error: conflicting types for `uint32_t' /usr/include/stdint.h:28: error: previous declaration of `uint32_t' make[1]: *** [img2srec.o] Error 1 make[1]: Leaving directory `/cygdrive/d/Profiles/apovolot/U-boot/u-boot-1.1.1/to ols' make: *** [tools] Error 2
On Fri, Jul 23, 2004 at 09:34:33AM -0400, Povolotsky, Alexander wrote:
apovolot@USPITLAD104868 ~/U-boot/u-boot-1.1.1 $ make MPC8260ADS_config Configuring for MPC8260ADS board...
apovolot@USPITLAD104868 ~/U-boot/u-boot-1.1.1 $ make all ............... make[1]: Entering directory `/cygdrive/d/Profiles/apovolot/U-boot/u-boot-1.1.1/t ools' gcc -Wall -pedantic -D__WIN32__ -I../include -I.. -DTEXT_BASE=0xfff00000 -DUSE_H OSTCC -O -c -o img2srec.o img2srec.c In file included from img2srec.c:60: ../include/elf.h:46: warning: redefinition of `uint8_t' /usr/include/stdint.h:24: warning: `uint8_t' previously declared here ../include/elf.h:47: warning: redefinition of `uint16_t' /usr/include/stdint.h:25: warning: `uint16_t' previously declared here ../include/elf.h:48: error: conflicting types for `uint32_t' /usr/include/stdint.h:28: error: previous declaration of `uint32_t' make[1]: *** [img2srec.o] Error 1 make[1]: Leaving directory `/cygdrive/d/Profiles/apovolot/U-boot/u-boot-1.1.1/to ols' make: *** [tools] Error 2
The attached patch fixes cygwin builds. inttypes.h has been included in cygwin for quite some time now, so we do not need all the __WIN32__ ifdef's.
-- Lars Munch
Lars Munch writes:
Lars> The attached patch fixes cygwin builds. inttypes.h has been Lars> included in cygwin for quite some time now, so we do not need Lars> all the __WIN32__ ifdef's.
First of all, Cygwin is a Linux-like environment and not WIN32 so there is no need to #define __WIN32__ in the Makefile. #ifdefs can be needed for other environments (mingw? Visual C?). The problem is in the order of header files because U-Boot host tools have to mix target and host headers and in some cases (including Cygwin) wrong files are #included. My patch from Jul 19th fixes this problem.
On Sun, Jul 25, 2004 at 12:31:26PM +0300, Yuli Barcohen wrote:
Lars Munch writes:
Lars> The attached patch fixes cygwin builds. inttypes.h has been Lars> included in cygwin for quite some time now, so we do not need Lars> all the __WIN32__ ifdef's.First of all, Cygwin is a Linux-like environment and not WIN32 so there is no need to #define __WIN32__ in the Makefile.
That is true, but on older cygwin systems that define was needed in order to build the tools. To me it looks like __WIN32__ should have been named __CYGWIN__ in the first place, since all the "#ifdef __WIN32__" in the tools directory are cygwin related and not VC++ nor mingw related.
Maybe we should just remove all the "#ifdef __WIN32__" from the tools directory since they are not needed any more for cygwin builds and has nothing to do VC++ nor mingw?
#ifdefs can be needed for other environments (mingw? Visual C?). The problem is in the order of header files because U-Boot host tools have to mix target and host headers and in some cases (including Cygwin) wrong files are #included. My patch from Jul 19th fixes this problem.
Sorry, I forgot about your patch.
-- Lars Munch
Lars Munch writes:
Lars> The attached patch fixes cygwin builds. inttypes.h has been Lars> included in cygwin for quite some time now, so we do not need Lars> all the __WIN32__ ifdef's.
Yuli> First of all, Cygwin is a Linux-like environment and not WIN32 Yuli> so there is no need to #define __WIN32__ in the Makefile.
Lars> That is true, but on older cygwin systems that define was Lars> needed in order to build the tools. To me it looks like Lars> __WIN32__ should have been named __CYGWIN__ in the first Lars> place, since all the "#ifdef __WIN32__" in the tools directory Lars> are cygwin related and not VC++ nor mingw related.
Probably you're right. I don't know the history of this #define but according to GCC documentation, "All names which begin with two underscores, or an underscore and a capital letter, are reserved for the compiler and library to use as they wish." So __WIN32__ should not be defined for the tools, which are just applications, if it's not pre-defined by the compiler. But #define is not the only problem. When I worked around the #define, mkimage was built with incorrect endianness, so I had to investigate the problem and found the includes order issue, which is fixed by the patch.
Lars> Maybe we should just remove all the "#ifdef __WIN32__" from Lars> the tools directory since they are not needed any more for Lars> cygwin builds and has nothing to do VC++ nor mingw?
I don't know if anybody needs them. There is Makefile.win32 in the tools directory so maybe somebody builds the tools on Win32 platform, though I suspect that nobody does. Maybe Wolfgang can answer your question...
On Mon, Jul 26, 2004 at 01:07:04PM +0300, Yuli Barcohen wrote:
Lars Munch writes:
Lars> The attached patch fixes cygwin builds. inttypes.h has been Lars> included in cygwin for quite some time now, so we do not need Lars> all the __WIN32__ ifdef's. Yuli> First of all, Cygwin is a Linux-like environment and not WIN32 Yuli> so there is no need to #define __WIN32__ in the Makefile. Lars> That is true, but on older cygwin systems that define was Lars> needed in order to build the tools. To me it looks like Lars> __WIN32__ should have been named __CYGWIN__ in the first Lars> place, since all the "#ifdef __WIN32__" in the tools directory Lars> are cygwin related and not VC++ nor mingw related.Probably you're right. I don't know the history of this #define but according to GCC documentation, "All names which begin with two underscores, or an underscore and a capital letter, are reserved for the compiler and library to use as they wish." So __WIN32__ should not be defined for the tools, which are just applications, if it's not pre-defined by the compiler. But #define is not the only problem. When I worked around the #define, mkimage was built with incorrect endianness, so I had to investigate the problem and found the includes order issue, which is fixed by the patch.
Ok.
Lars> Maybe we should just remove all the "#ifdef __WIN32__" from Lars> the tools directory since they are not needed any more for Lars> cygwin builds and has nothing to do VC++ nor mingw?I don't know if anybody needs them. There is Makefile.win32 in the tools directory so maybe somebody builds the tools on Win32 platform, though I suspect that nobody does. Maybe Wolfgang can answer your question...
I also suspect that nobody uses Makefile.win32 to build a "native windows" mkimage.exe since mkimage uses "mmap" and that function is not available on windows (on native windows you would use "CreateFileMapping" instead).
I'll make a new patch which completely removes __WIN32__ from the tools directory.
-- Lars Munch
In message 16644.55240.247936.149533@astp0002.localdomain you wrote:
Lars> Maybe we should just remove all the "#ifdef __WIN32__" from Lars> the tools directory since they are not needed any more for Lars> cygwin builds and has nothing to do VC++ nor mingw?I don't know if anybody needs them. There is Makefile.win32 in the tools directory so maybe somebody builds the tools on Win32 platform, though I suspect that nobody does. Maybe Wolfgang can answer your question...
Me? God forbid! I never worked under Windoze, and never will. I have not the slightest idea what of this is working or not or in use by anybode. This is an area where I have to rely exclusively on contributions.
Best regards,
Wolfgang Denk
participants (4)
-
lars＠segv.dk -
Povolotsky, Alexander -
Wolfgang Denk -
Yuli Barcohen