libstdc++ libtool lossage
David Edelsohn
dje@watson.ibm.com
Sat Feb 23 09:01:00 GMT 2002
>>>>> 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
More information about the Java-patches
mailing list