Re: A completely different approach to EH runtime

["H . J . Lu" <hjl at valinux dot com>]

On Wed, Feb 21, 2001 at 07:40:27PM -0300, Alexandre Oliva wrote:
> 
> > Now a RedHat 8.0 user wants to try gcc of the day from CVS or gcc
> > 3.0.2. Will the new libgcc_s.so be configured/built and where will
> > it be installed?
> 
> I'd advise people to install other versions of GCC in other
> directories.  I suppose they won't be building programs used during
> start-up with this new version of GCC.  Only if they do does
> libgcc_s.so become ``part of the system'' and has to be copied to
> /lib.  A user that goes to the trouble of (i) installing a different
> version of GCC from the one shipped with their GNU/Linux distribution,
> and (ii) *replacing* system files with programs build with this new
> compiler can be expected to also take the trouble of (iii) updating
> /lib/libgcc_s.so with some version that will work with their new
> system binaries.
> 
> But I'm pretty sure a very small number of users will take step (ii).
> These users may happen to be burned once, then RTFM (yet to be written
> :-) and learn to also take step (iii) in these situations.  Users that
> never take steps (i) or (ii) don't have to worry about step (iii).

Do you think it will encourage Linux people to try new gcc?

> 
> > What if there is a bug in the new gcc which miscompiles libgcc_s.so?
> 
> Is this any different from having a bug in a new version of glibc?
> Upgrading the system libgcc_s.so is no different from upgrading the
> system libgcc_s.so.

Exactly! That is the whole point. The normal Linux people get their
new glibc from the Linux vendor, not ftp.gnu.org. They normally only
get one copy libc.so on their machines.

> 
> > Do you think Red Hat will recommend the random users to try new gcc
> > and install libgcc_s.so under /lib?
> 
> Probably not.  And this won't be necessary as long as GCC arranges for
> programs built with it to search for libgcc_s.so in its installation
> directory.  However, if GCC doesn't do that, and the user adds the new
> GCC's libdir to ld.so.conf, then all existing programs may be
> affected.  This is probably not advisable.  Unless /lib searched
> before any directory listed in ld.so.conf, LD_LIBRARY_PATH or DT_RPATH
> (sp?), in which case there's just no way to test a new libgcc_s.so
> without replacing the system's version.  That would be a problem.
> 

Glad to hear you are starting to see the problem :-). It is no different
form the normal glibc upgrade problem. That is one reason why we don't
recommend random Linux users to try new glibc themselves -). libc.so is
the last thing they should mess around with.

-- 
H.J. Lu (hjl@valinux.com)