Re: A completely different approach to EH runtime

[Joe Buck <jbuck at synopsys dot COM>]

> In general, the user has to set LD_LIBRARY_PATH to get libgcc_s.so in
> /path/to/other/lib. But when he/she does that, every single binary
> she/he runs, including 'ls', will use /path/to/other/lib/libgcc_s.so.

But that's OK, if we do our jobs right.

Case 1: ls was built by a pre-3.0 compiler.  In this case, ls will not
have any undefined symbols that are defined in libgcc_s.so, so it doesn't
matter.

Case 2: ls was built by 3.0, and the user is testing 3.1-beta1, which
is installed with prefix /opt/gcc-3.1-beta with libs in /opt/gcc-3.1-beta/lib.
ls will now get the new libgcc_s.so.  However, this new library will
provide all of the same symbols and ABIs as the old library (plus,
possibly, some new ones).  ls still runs just fine.

So where is the problem?  It appears that you are implicitly assuming
that the gcc maintainers are incapable of doing, for a much smaller
library, what the glibc maintainers are doing successfully for a much
larger library: maintaining backward compatibility.

> Even if you use -rpath,
> which I don't like, it will means all DSOs, including those come with
> the system, opened by the new binary will use the new libgcc_s.so in
> /path/to/other/lib. Do you think it is safe to do so? If yes, why not
> put the new libgcc_s.so in /lib?

People should be able to test gcc on machines where they don't have root.