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

[Vasili Galka]

Hi Jeroen,

On Thu, May 22, 2014 at 9:27 PM, Jeroen Hofstee <dasuboot at myspectrum.nl> wrote:
> Hello Vasili,
>
> On wo, 2014-05-21 at 11:50 +0300, Vasili Galka wrote:
>
>> >>    This pattern is a
>> >>    result of the original decision from 2004 to prioritize the host
>> >>    include paths over the paths from U-Boot tree.
>> >
>> > any reference?
>>
>> This decision is a part of the above mentioned commit: e1a3f6b (July 2004)
>> I don't know how much the original committer was aware of its long
>> term implications.
>
> If the only valid reason is "Fix host tools building in Cygwin
> environment" as mentioned in the original commit, then I am all in favor
> of dropping it and finding a decent solution for cygwin.
>
>> >> 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.
>> >
>> > I have no idea why it is the way it is, but keep in mind that e.g. stdio
>> > headers in u-boot is quite something different then stdio for the target
>> > userland.
>>
>> Sure. I'll keep it in mind while I'm designing a solution here. I'm
>> afraid there is no easy way to fix it though.
>>
> This is easier than it sounds. U-boot is build with -nostdinc for the
> binary itself. And it tries to get the compiler related includes back
> with "isystem $(shell $(CC) -print-file-name=include". (and the printf
> declaration and friends are actually in common.h for the loader, which
> makes it even harder to do it wrong by accident).
>
> Can you check what "arm-none-eabi-gcc -print-file-name=include" returns
> on cygwin?
>
> mmm, this one might be also be a challenge for cygwin:
> "dirname `arm-none-eabi-gcc -print-libgcc-file-name`", but you will
> likely get linker errors if that contains spaces / backslashes or simply
> fails.
>
> But perhaps even easier, can you post the problems you encounter if you
> remove the idirafter. Likely easier then guessing what can go wrong in a
> cygwin build.
>
> Regards,
> Jeroen
>
>

Let's suppose there is an application in tools directory that requires
both "libfdt_env.h" (from uboot tree) and "errno.h" (from host
environment). However, as both headers exist at both places, in the
uboot tree and on the host environment, there is no way to solve this
just by altering the include paths order. For any reshuffling both
headers will be taken either from uboot or from host - which is
undesired.

I can only think of one bulletproof solution that would fix the above
problem. Unfortunately it's conceptual and requires much work:
* Currently, almost all include derectives in in uboot code use <>
style. I propose to modify this concept.
* For each #include directive the developer shall decide from where
the header file is obtained - U-Boot source tree or the host
environment.
* Depending on that, "" shall be used only for headers from U-Boot
tree, <> shall be used only for all other (host provided in tools
folder)
* The -iquote compiler flag can be used for adding "" search paths.
The -I flag for adding <> paths.

Of course that's just a draft of the idea. What do you think?

Best,
Vasili