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

[Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>]

On Mon, Jul 02, 2001 at 02:16:34AM +0200, 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.

I'd like to point at symbol versioning here.  This is what it's for,
and why we use it.  The existing function, on input valid to the old
version, works as expected; but on new input it behaves in a new way. 
You can have two aliases to it, with different versions, and make the
new version the default at link time.

Also note that this has nothing to do with the current argument, as
best I can tell.  The same thing would have happened if the new libgcc
had not been installed at all; it seems that HJ is mostly objecting to
the way it is getting installed and where.

>    ./configure --prefix=/usr
>    make bootstrap
>    make install
> 
> would replace my current GCC with a new one without too much hassle.
> But I think it already does, despite what HJ says.

Does it behave correctly in overwriting libgcc?  My reading of
install-sh suggests that it should be fine.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer