From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeroen Hofstee Date: Thu, 22 May 2014 20:27:29 +0200 Subject: [U-Boot] Building under Cygwin - "-ansi" flag? In-Reply-To: References: <20140509150821.GI22182@bill-the-cat> <1400609217.2002.37.camel@yellow> Message-ID: <1400783249.2075.26.camel@yellow> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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