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