On Sun, May 11, 2014 at 1:27 PM, Vasili Galka vvv444@gmail.com wrote:
On Fri, May 9, 2014 at 6:08 PM, Tom Rini trini@ti.com wrote:
On Thu, May 08, 2014 at 02:49:35PM +0300, Vasili Galka wrote:
Hi,
I'm building u-boot (am335x_evm config) using arm-none-eabi toolchain under Cygwin. When trying to build unmodified v2014.04 tag I get some errors. However, if I remove the "-ansi" flag from the Makefile, everything builds fine:
-ifeq ($(HOSTOS),cygwin) -HOSTCFLAGS += -ansi -endif
I tried tracking down where those lines came from and why building under Cygwin requires separate treatment. I found our this originates from the following commit (dated Jan 2008):
SHA-1: 883e3925d99a8dd69c5b0201cba5b1887f88f95c
- Fix build problems under Cygwin
This patch allows u-boot to build without error in a cygwin environment. Cygwin does not define __u64 in it's include/asm/types.h file. The -idirafter flag in the u-boot build causes the inclusion of the cygwin types.h file as opposed to u-bot/include/asm/types.h file which does define __u64. Subsequently, sha1.c compile fails due to unknown symbol.
Signed-off-by: Brian Miller raptorbrino@netscape.net
This comment does not really explain why "-ansi" flag is required.
-ansi changes include order perhaps?
Personally, I don't see any reason for it.
Maybe it should be removed at all?
Yes, but can you please test a few more builds? If you're able to use MAKEALL, please run MAKEALL -a arm
-- Tom
Hi Tom,
There are indeed some errors, I look into it later and keep you updated.
Best, Vasili
Dear Tom,
I've finally found time to look deeper into this problem. Let me outline the situation: 1. The problems with Cygwin build arise in code built for the "host" architecture i.e. stuff in "tools" sub-directory. 2. Along the years, there were several commits targeting the problems. All were related to include search paths/their order: a. e1a3f6b (July 2004): U-Boot include paths for "tools" build were changed to "-idirafter", i.e. host headers were given higher priority than headers in U-Boot tree. b. 883e392 (Jan 2008): The above patch caused "asm/types.h" shipped with Cygwin to be included. Turned out Cygwin does not define __u64, so this patch tried to workaround it by adding the "-ansi" flag. This flag dropped some include search paths effectively returning the use of "asm/types.h" from U-Boot tree. c. 669dfc2 (March 2013): Yet another header was included from the host paths and caused problems: "libfdt_env.h". This time it was worked around by adding the following flag to override it: "-include $(SRCTREE)/include/libfdt_env.h" 3. Currently all builds fine on Linux. However, on Cygwin some configs fail to build since not all the code complies with the ANSI standard. On the other hand, removing the "-ansi" flag causes build errors in other configs due to reasons explained above.
Now my thoughts on the situation: 1. Requesting compliance of U-Boot code with the ANSI standard is an overshoot. It was used as a workaround to a problem and a different solution shall be found. There is already a code that does not compile with it. Speaking of it, is there a policy about U-Boot code compliance to some standard? C99? GNU99? If not, I think it's important to define one and stick to it. This will eliminate uncertainty and simplify things in the future. 2. I see a reoccurring pattern of some headers being used from the host, causing mismatches and arising build errors. Then some way is sought to include headers from U-Boot tree prior to them which solves the problem. This happens for both Linux and Cygwin. This pattern is a result of the original decision from 2004 to prioritize the host include paths over the paths from U-Boot tree. I see this happening again and again with different headers in the future. So here comes the question, is it really the right thing prioritize the include paths this way? Why do host paths MUST come first? I'll try reverting this locally and looking what breaks and what alternative solutions exist.
P.S. I'm building all with arm-none-eabi toolchain. I set up powerpc-none-eabi toolchain under Linux and got some build errors. I'll open a separate thread about it.
Best regards, Vasili