This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++ libtool lossage
- From: David Edelsohn <dje at watson dot ibm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>, Richard Henderson <rth at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 24 Feb 2002 18:30:56 -0500
- Subject: Re: libstdc++ libtool lossage
>>>>> Jakub Jelinek writes:
Jakub> So on AIX and maybe other platforms which are not happy about having the
Jakub> same library as shared and static on the command line we had correctness
Jakub> issues. AIX used some permission magic in t-aix43 since Sep 2001. In
Jakub> late December/January, David changed this, but changed only one of the two
Jakub> occurences of shared_name, static_name pairs (the -shared and !-shared-libgcc
Jakub> and !-static-libgcc) while left -shared-libgcc in (this was after
Jakub> PT_GNU_EH_FRAME changes which were commited at the same time feature freeze
Jakub> started).
The permission magic on AIX was a kludge that covered up part of
the EH problem and only worked some of the time. It was not a correct
solution. It caused AIX to load the shared library at an address which
did not have the sign bit set, covering up the sorting / binary search
error in the unwinder. Only when I found the real problem did I
understand why that kludge worked. I originally thought it was a sharing
problem.
When the divide and mod routines were changed to throw exceptions,
the kludge stopped working.
I did not change -shared-libgcc to only link against the shared
libgcc.so because the original purpose of that options was for linking
executables, not shared objects. libgcc.a provides special routines not
in libgcc.so needed by some executables. When this new use of
-shared-libgcc arose, I had forgotten why I had not changed it originally.
David