This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A completely different approach to EH runtime


> > > 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]