This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GCC vs GLIBC: why this stance, Drepper ?!?



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]