This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC vs GLIBC: why this stance, Drepper ?!?
- To: Mark Kettenis <kettenis at wins dot uva dot nl>
- Subject: Re: GCC vs GLIBC: why this stance, Drepper ?!?
- From: Davide Libenzi <davidel at xmailserver dot org>
- Date: Sun, 01 Jul 2001 17:35:43 -0700 (PDT)
- Cc: mark at codesourcery dot com,gcc at gcc dot gnu dot org
On 02-Jul-2001 Mark Kettenis wrote:
> Anyhow, suppose you're on a system that uses GCC as its system
> compiler, with libgcc_s.so.1 in /lib or /usr/lib. Now suppose that
> the system administrator installs a new version of GCC in /usr/local,
> and that this version of GCC comes with a libgcc_s.so.1 that is
> backwards compatible, but not quite forwards compatibles. Support for
> some new DWARF2 opcodes generated by the new GCC would be a good
> example.
>
> People start using the new compiler, but don't set RPATH/RUNPATH
> and/or LD_LIBRARY_PATH. When they run their C++ programs, the old
> libgcc_s.so.1 from the system compiler gets used and their C++
> programs fail for some mysterious reason, perhaps with a segmentation
> fault when it throws an exception. The solution is simple. Setting
> LD_LIBRARY_PATH fixes the problem. Upgrading the system libgcc_s.so.1
> is another option. But how do you detect this from a user's bug
> report?
>
> I'm not sure what can be done about this. I don't think any of the
> GCC developers has access to a crystal ball. I hope this convinces
> you that one has to treat libgcc_s.so.1 with extreme care. And
> perhaps it is possible to plan ahead and make things fail in an
> obvious way if code compiled with a new GCC is used in conjunction
> with an old libgcc_s.so.1.
Isn't it possible to split libgcc into one, small, static, version dependent
library and one shared that you'll try to keep the more version compatible as
possible ?
- Davide