This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++ in a combined tree
> The key problem is that we have two ways
And then he lists *three* ;-)
> * Hard-coded information about the target
I seem to recall a long time ago, talk of a global target capabilities
database. It proved too unwieldy to implement. However, a toplevel
configury snippet (aka config.gcc) might (1) prove useful, and (2)
speed up configure.
> To me, it ought to be a fundamental invariant that the same features
> are enabled for cross and native compilation.
That would be a good goal.
> To accomplish that, we need to avoid autoconf tests for features that
> require running target programs;
The problem I'm running into is that I can't even *link* a target
program at that point. The C library (including crt0 and linker
scripts) have not yet been installed.
> Hence, my opinion is that we ought never to use autoconf tests to
> figure these things out, even for native compilation, relying
> instead on hard-coded target information of --enable-* flags.
Such as --enable-libfoo-a ?
> To that end -- and I know this is going to be unpopular -- I think we
> should require that you have a C library available at libstdc++ build
> time, either by having one already installed, or by passing appropriate
> -I/-L options to libstdc++.
We normally pass the newlib -I/-L, but in my case, I also need to
point into libgloss for a few things. That gets nasty as there's no
consistency there.