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