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: A completely different approach to EH runtime


On Feb 21, 2001, "H . J . Lu" <hjl@valinux.com> 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).

> 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.

> 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.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me


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