[U-Boot] Building under Cygwin - "-ansi" flag?

[Vasili Galka]

On Sun, May 11, 2014 at 1:27 PM, Vasili Galka <vvv444 at gmail.com> wrote:
>
> On Fri, May 9, 2014 at 6:08 PM, Tom Rini <trini at 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 at 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