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 Wed, Feb 21, 2001 at 10:34:17PM -0800, H . J . Lu wrote:
> On Thu, Feb 22, 2001 at 05:03:51AM +0000, Joern Rennecke wrote:
> > >
> > > On Wed, Feb 21, 2001 at 07:56:00PM -0300, Alexandre Oliva wrote:
> > > > On Feb 21, 2001, "H . J . Lu" <hjl@valinux.com> wrote:
> > > >
> > > > > Just think about you have more than libc.so.6 on your Linux machine in
> > > > > different direcories and they are both visibible to ld-linux.so.2. Can
> > > > > you tell me what may happen?
> > > >
> > > > I see a few possible scenarios:
> > > >
> > > > - it picks the first one it finds.
> > >
> > > That won't work since some binaries may need the newest one.
> >
> > This would indicate that either the old library was broken - than you
> > should replace it - or that the new library has additional functionality -
> > than its minor version should be incremented; then the dynamic linker
> > will pick the newer library for programs that have been linked with the
>
> The ELF dynamic linker doesn't work this way. It will use the first
> DSO with the right soname. You just have to make sure the right DSO
> is found by the dynamic linker. With libc.so, we only have one in
> /lib.
If we add symbols to libgcc_s.so, they will have a different symbol
version (GCC_3.1 or something). The dynamic linker will be faced with
binary uses: GCC_3.0 GCC_3.1
/lib/libgcc_s.so: GCC_3.0
/path/to/other/lib/libgcc_s.so: GCC_3.0 GCC_3.1
I don't know if it is intelligent enough, in this context, to link
only the libgcc_s.so in /path/to/other/lib. However, it will pick one
or the other, and the worst that happens is an undefined symbol
error. Then the user has to set LD_LIBRARY_PATH.
[IMO, if it were to link _both_, that would be a bug.]
zw