From: Jeroen Hofstee <dasuboot@myspectrum.nl>
To: u-boot@lists.denx.de
Subject: [U-Boot] Building under Cygwin - "-ansi" flag?
Date: Thu, 22 May 2014 20:27:29 +0200 [thread overview]
Message-ID: <1400783249.2075.26.camel@yellow> (raw)
In-Reply-To: <CA+gZxsPxJoXpvxyHdgUb=N6=j2Mq6qYCmskbYFjXX7jvCOW+2Q@mail.gmail.com>
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
next prev parent reply other threads:[~2014-05-22 18:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-08 11:49 [U-Boot] Building under Cygwin - "-ansi" flag? Vasili Galka
2014-05-09 15:08 ` Tom Rini
[not found] ` <CA+gZxsNyypaz+Qf2DyDDX0tQY=+dr6J=ym2joKfJS9GqcnwNTg@mail.gmail.com>
2014-05-19 9:45 ` Vasili Galka
2014-05-20 18:06 ` Jeroen Hofstee
2014-05-21 8:50 ` Vasili Galka
2014-05-22 18:27 ` Jeroen Hofstee [this message]
2014-06-05 12:51 ` Vasili Galka
2014-06-06 10:43 ` Masahiro Yamada
2014-06-06 12:13 ` Vasili Galka
2014-06-06 10:42 ` Masahiro Yamada
2014-06-06 10:58 ` Masahiro Yamada
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1400783249.2075.26.camel@yellow \
--to=dasuboot@myspectrum.nl \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.