Re: libstdc++ in a combined tree

[Mark Mitchell <mark at codesourcery dot com>]

DJ Delorie wrote:
>> The key problem is that we have two ways
> 
> And then he lists *three* ;-)

:-)

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

Right, I understand.  Assuming that they exist at this point, you could
theoretically pass enough options to make it work -- although, as you
say, it's hard to know what those options ought to be.  If everything is
set up right, it's -I options (for libc headers), -L options (for libc
and libgloss), and a -T option (for appropriate linker script).

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

In this case, for example, --enable-libstdc++-symvers, or some such.

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

Personally, I'd just not do a one-tree build. :-)  But, I know that's
popular with lots of folks, for various reasons, including not having to
build the compiler twice.

The thing I'd discourage you from doing is running autoconf only in some
configurations (e.g., only if native, or only if $build = $host).  In
particular, adding a configure option which is unconditionally honored,
if present, but falling back to autoconf if it's not present, doesn't
bother me; that still doesn't introduce any differences based on whether
we're in a cross, native, or Canadian configuration.

It might be that it's more expedient to add such a configure option than
to fix things so that you can link, but, really, first and foremost, I'd
encourage you to fix things so that you can link.  (One big-hammer
solution there is to revive the "staged install" proposal, where you
would do something like "make install DESTDIR=$objdir/install" after
building each component, so that Newlib, libgloss, etc., would already
be in this staging area, before building libstdc++.  I think that would
simplify a lot of our Makefiles -- but, of course, necessitate a fair
bit of change.)

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713