Re: A completely different approach to EH runtime

[Joe Buck <jbuck at synopsys dot COM>]

> How can you be 100% sure your libgcc is always newer than the one in
> /lib?  How about ls is built by 3.1 and I want to try 3.0.1? Or
> you installed gcc 3.0.1 and ls is now upgraded to the one built by
> gcc 3.0.2?

First off, it is quite likely that libgcc_s will be functionally identical
between those three releases, so there will be no issue at all.

If some new facility is added to libgcc_s, it would be in a major and
not a minor release, so there would be no issues with regard to 3.0.1
vs 3.0.2.  Otherwise it will be the same ABIs, same names, no more, no
less.

But let's take your first case, where 3.0.1 is installed with prefix
/opt/3.0.1 and libgcc_s.so is in /opt/3.0.1/lib.  The solution is
simple: delete /opt/3.0.1/lib/libgcc_s.so.  Then all binaries, old
and new, will get /lib/libgcc_s.so.  Since it's backward-compatible,
everything works.

Now let's take your second case, changing gcc 3.0.2 to gcc 3.1, since
we're saying we're not allowing interface changes to libgcc_s.so in minor
releases.  Furthermore let's say that ls, as built with 3.1, uses a
function in libgcc_s.so that wasn't in the 3.0.1 version.  THIS IS VERY
UNLIKELY.  The case where I forsee a change happening first is for
exception handling on IA64 systems, so certainly this issue doe have to be
handled at least there.  And you're right, it is a possibility on other
systems.  How to handle it?

Here's one possibility: GNU/Linux distributors put libgcc_s.so in its
own package, and specify that a program built with 3.0.x depends on
libgcc_s version 3.0 and with 3.1 we depend on 3.1.  This Depends:
argument only needs to be changes when there is a backward-compatible
but not forward-compatible change.  When a user attempts to install
the new ls as you suggest, apt-get or Red Carpet or whatever
will automatically get the new libgcc_s package.

> > People should be able to test gcc on machines where they don't have root.
> 
> Isn't that the same problem to test glibc? As I said before, having the
> shared libgcc under Linux puts libgcc in the same category as glibc. Do
> you really think you have seen something new with shared libgcc we
> haven't seen in glibc before?

Yes, there are similar problems, but libgcc_s is a vastly smaller library,
therefore the problems are manageable.  Surely you are not claiming that
you are not capable of testing a a new glibc on a box with an old glibc
installed?