Re: libstdc++ in a combined tree

[Mark Mitchell <mark at codesourcery dot com>]

DJ Delorie wrote:
> Another one like libssp.
> 
> In libstdc++-v3's configure.ac, we see this:
> 
> # This depends on GLIBCXX CHECK_LINKER_FEATURES, but without it assumes no.
> GLIBCXX_ENABLE_SYMVERS([yes])
> 
> The comment lies.  If we haven't yet checked the linker features, it
> will check them, and configure will fail in a combined build because
> newlib/libgloss hasn't yet been installed.
> 
> Since we already check for cross compiling, I've been using this
> conditional instead:
> 
> if test x"$gcc_no_link" = xyes; then true; else
>   # This will run GLIBCXX CHECK_LINKER_FEATURES, so we can't use it if we can't
>   # build executables.
>   GLIBCXX_ENABLE_SYMVERS([yes])
> fi
> 
> but of course this will drop support for cross compiled linux targets
> having symbol versioning.  Suggestions?

The key problem is that we have two ways of determining what features to
enable and use:

* Autoconf tests

* Hard-coded information about the target

* --enable-* flags to configure

To me, it ought to be a fundamental invariant that the same features are
enabled for cross and native compilation.

To accomplish that, we need to avoid autoconf tests for features that
require running target programs; we must hard-code those.  We could
hard-code everything, but that becomes difficult, because your target
foo-*-bar system isn't quite the same as mine.  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.

I think it makes sense to use autoconf for everything that doesn't
require a runtime test, to the extent possible.

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++.  IIUC, Cygwin has some complicated
dependencies that make this difficult.  (That's why I assume this
suggestion isn't going to be popular.)

Assuming people won't accept that restriction, then we ought to either
(a) hard-code this choice, or (b) depend on a --enable-* flag.  I think
it should be considered bad policy to make things work differently for
native/cross environments.

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