Re: libstdc++ in a combined tree

[DJ Delorie <dj at redhat dot com>]

> 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.