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


On Wed, Feb 21, 2001 at 11:53:36PM -0800, H . J . Lu wrote:
> On Wed, Feb 21, 2001 at 11:44:20PM -0800, Zack Weinberg wrote:
> > > 
> > > The ld.so in glibc will check GCC_3.0 and GCC_3.1 AFTER libgcc_s.so
> > > is loaded, not before.
> > 
> > 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.

zw


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