Re: A completely different approach to EH runtime

[Joe Buck <jbuck at synopsys dot COM>]

I wrote:
> > Because dynamic linking may have subtle differences on different systems,
> > we will perhaps need OS-specific instructions to make sure that this is
> > the case.  On SVR4-like systems, having the new libgcc be the first match
> > in LD_LIBRARY_PATH should suffice.
>  
> That is only true for non-suid programs.

That's not a problem; the suid programs will continue to use the system
path, which will almost certainly correspond to the exact compiler that
built that suid program.

> But even with LD_LIBRARY_PATH
> there are several problems. One of them is all the programs you run
> will use that libgcc. It should be ok for the binaries compiled with
> the gcc you built. But it may not be ok for the system binaries
> compiled with a different gcc.

At the risk of repeating myself: I know, and this is OK if we do our
jobs right.  The newer libgcc_s must be forward-compatible with the
system libgcc_s, that's all.

> As I said many times, you don't want to
> have more than one libc.so or libgcc_s.so on your machine.

You've said it but I don't buy it: your requirement is too strict.
Rather, if you have an additional libc.so or libgcc_s.so, it must be a
*newer* version than the system version (the system version is the one in
/lib), so that, if LD_LIBRARY_PATH points to these new versions, the
system executables (like ls) continue to execute correctly.

> Having only
> one libc.so/libgcc_s.so makes all those problem to go away.
> 
> You are entering a territory you have never been in before. Please
> listen to people who have been there before. When Ulrich and I said it
> wouldn't work, it is most likely to be true. I may even have missed
> some other problems with 2 libc.so or libgcc_s.so.

Appeals to authority will get you nowhere.  I know of no developer, no
matter how god-like, who hasn't occasionally been wrong.

I say that there is no problem with having two libc.so's on your GNU/Linux
box provided that the following is true:

1. The older version is the "system" version (installed in /lib).
2. The newer version appears first in a user's LD_LIBRARY_PATH.
3. The newer version provides all the symbols that the older version
   did, with compatible ABIs, but may provide additional symbols as well.

The same is true for libgcc_s.so, except that for the latter it is a
much simpler problem to satisfy condition #3.

Now it is quite possible that I am wrong, but if so, please provide a
scenario demonstrating the problem.  I am uninterested in hearing you
claim "Ulrich says it won't work".  GIVE AN EXAMPLE.