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
- To: zackw at Stanford dot EDU (Zack Weinberg)
- Subject: Re: A completely different approach to EH runtime
- From: Joern Rennecke <amylaar at cambridge dot redhat dot com>
- Date: Thu, 22 Feb 2001 08:29:10 +0000 (GMT)
- Cc: hjl at valinux dot com (H . J . Lu),amylaar at cambridge dot redhat dot com (Joern Rennecke),aoliva at redhat dot com (Alexandre Oliva), gcc at gcc dot gnu dot org
> > > 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?