Re: A completely different approach to EH runtime

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

On Thu, Feb 22, 2001 at 10:08:38AM -0300, Alexandre Oliva wrote:
> On Feb 21, 2001, "H . J . Lu" <hjl@valinux.com> wrote:
> 
> > Are you prepared to deal with 2 shared libgcc visible to ld.so at
> > the same time and one of which doesn't come from the system vendor?
> 
> I don't know about you, but I am, for as long as libgcc's major
> version number doesn't change.

I have given at least one example to show it won't work. Please
read my replies to Per.

> 
> As soon as it does, we'll have major hassles just like in the libc5->6
> migration: there will be shared libraries linked with an old and the
> new versions of libgcc.  No program should link with two such
> libraries.  As usual, I have a feeling that SONAMEs should contain not
> only the SONAME of the library itself, but also of all its
> dependencies.  Not that it would help with this problem (this one just
> can't be helped, I think), but at least it would be easier to maintain
> multiple versions of the same library, with its own external version
> number, but with different sets of dependencies.

Do you know as far as the dynamic linker is concerned, a new SONAME is
a totally different shared library?

> 
> I understand a hack in ld.so helped overcome the difficulties in the
> libc5->6 migration, but I think we'd better avoid it completely for
> libgcc.  If libgcc's interface *ever* drops a symbol, introducing
> binary incompatibility, we'll have major difficulties in dealing with
> the situation that will arise.  I believe that's the main problem
> you're trying to get us to ponder about, right?
> 

No. I don't think we should do that. I am talking about adding new
symbols. In that case, you have to make sure

1. The new libgcc is 100% compatible with the old one.
2. Only the new libgcc is visible to ld.so.

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