This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A completely different approach to EH runtime
On Thu, Feb 22, 2001 at 08:29:10AM +0000, Joern Rennecke wrote:
> > > > Mm, but couldn't it notice that it loaded the wrong one, unload it,
> > > > and look for another one? It's not like we only notice ages later
> > > > when it tries to lazily bind a missing symbol. It knows the symbols
> > > > are missing as soon as the wrong library is loaded.
> > > >
> > >
> > > I don't know if there is any ELF dynamic linker which does that. I
> > > don't believe this behavior is specified in the ELF specs. In fact,
> > > the ELF specs only mentions the soname. You can certain come up with
> > > a fancy dynamic linker to do that. But we, glibc, only do ELF. Since
> > > we are talking glibc, please limit yourselves to ELF and the GNU
> > > symbol versioning.
> >
> > What I'm saying is that I think that 'given N libraries with the same
> > soname, choose the one that satisfies all the symbol version
> > requirements' should be the semantic of GNU symbol versioning. I
> > recognize that it's not that way now, but it should not be hard to
> > change.
> >
> > gcc can't count on this behavior even if glibc does implement it, but
> > it would make life much easier on glibc-based platforms.
>
> Wouldn't it be a lot easier to teach the linker how to handle minor
> version numbers?
Given that the SunOS 4 linker did that, and the ELF spec forbids it, I
figure there was a good reason why it didn't actually work.
zw