On 03/09/15 16:22, Aldy Hernandez wrote:
Hello gentlemen.
The problem here is that we pick up the system's CFLAGS and pass it down
to the target libraries. This causes havoc when, for instance, CFLAGS
is -march=x86-64 and the target is powerpc-linux.
I don't see in what scenario the toplevel shell's CFLAGS would be of any
use in the target libraries, so I've just avoided that code path
altogether.
Tested by doing a cross-build from x86-64 to ppc64-linux-gnu in a
combined tree, and seeing if libgcc starts to build. Previously we
would fail while configuring GCC. Now, gcc builds fine, and the target
libraries start to build.
OK for mainline?
Aldy
curr
commit f2d130b93f334c5c680761553624964f87594adf
Author: Aldy Hernandez<al...@redhat.com>
Date: Mon Mar 9 15:12:33 2015 -0700
PR bootstrap/25672
* configure.ac: Do not initialize CFLAGS_FOR_TARGET from CFLAGS if
cross-compiling. Similarly for CXX_FOR_TARGET.
* configure: Regenerate.
I was wondering when someone would come across this oldie-but-goodie...
I'm sure someone, somewhere will complain that
make CFLAGS="whatever" isn't being passed down to the crossses as it has
been for the last two decades. And they'll be right.
But in the cross compiler case, I think it's reasonable to expect to
have to use CFLAGS_FOR_TARGET so that we have separation between the
host and target flags. One could easily want to compile the host with
one set of arguments and the target libraries with something completely
different.
And note that the various .mt files already use the _FOR_TARGET macros
to pass down additional flags rather than just CFLAGS or CXXFLAGS.
Are there any docs that need to change? I don't recall any offhand, but
if you could look prior to committing, it'd be appreciated.
OK for the trunk.
jeff
