PATCH RFA: Build system: Check for -static-libstdc++

[Ian Lance Taylor]

Dave Korn <dave.korn.cygwin@gmail.com> writes:

>   Yes, but what about the _usual_ difficulties of having two independent
> copies of a library linked into the same executable?  We may not be using
> new/delete or throwing exceptions in the compiler just yet, but it still looks
> really like an accident waiting to happen to me.
>
>   For example: suppose there's a pair of functions in gmpxx or ppl or cloog,
> called from the middle-end of the go1 executable, that allocate and deallocate
> some object or other; suppose the allocate function is an extern, prototyped
> in the related lib's header file, but the deallocator is inline; go1 calls the
> allocater, which invokes the system libstdc DSO's operator new; then go1 calls
> the deallocater, which gets inlined, and ends up invoking the
> statically-linked libstdc's operator delete.  Couldn't that happen?

I don't think that can happen for libraries explicitly mentioned on the
link line.  The linker will see the reference in the shared library, and
will pull in the function from the statically linked libstdc++.

For what it's worth, on my Ubuntu system I do not see any references to
libstdc++.so from the system libgmp, libmpfr and libmpc libraries.  So
the references are presumably coming from PPL, and we already have
special configure options to handle the difficulties which arise in that
case.  I think it's fine to continue requiring those configure options,
as long as the default works in a way that people find easy to use.

Ian