Re: libstdc++ libtool lossage

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Alexandre Oliva writes:

Alexandre> And that's precisely the intent of this flag.  As RTH and Jakub
Alexandre> explained, GNU/Linux doesn't need to link C shared libraries with
Alexandre> libgcc_s.so, as long as a sufficiently recent version of binutils is
Alexandre> in use.

Alexandre> The problem was that libstdc++-v3 and libjava, that are not C shared
Alexandre> libraries, use gcc, not g++ nor gcj, to create their libraries,
Alexandre> otherwise they'd have to be linked against themselves.  That's why
Alexandre> they have to use -shared-libgcc in addition to -shared.

	That is not the intended use of -shared-libgcc.  "gcc -shared
-shared-libgcc" is redundant and wrong.  I do not think that Mark agrees
with those semantics either.  Maybe your argument will convince him to
change his mind.  We will find out when he has a chance to read this
thread.

	You are defining conflicting semantics for "gcc -shared" (on
systems that support shared libraries) depending on the target OS and
binutils -- either linking with shared libgcc or with static libgcc.  That
is asking for problems.

	If you need something special for your target, make a
target-specific change, e.g., override CXX_FOR_TARGET in top-level config
or some other target-dependent location.

	You have started pulling on a thread and now are fixing symptom
after symptom instead of questioning whether the original interaction
between "-shared" and LINK_EH_SPEC and binutils was flawed.  Maybe you are
trying to have "gcc -shared" mean two different things?  Please step back
and re-assess the situation.

	Your patch has caused a regression in GCC.  I will request that
your patch be reverted if the regression is not fixed.

David