[Bug target/26472] Default path for libgcc_s.sl is build directory

["dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca  2006-03-10 01:25 -------
Subject: Re:  Default path for libgcc_s.sl is build directory

> > Attached.  The diff is against libtool in binutils as about July 28, 2005.
> 
> Similar changes have entered both branch-1-5 and HEAD Libtool more than 2 years
> ago; branch-1-4 is long dead.  I can only guess that's why it was ignored. ;-)
> 
> HPPA support has evolved a bit since.  There is BTW a pending patch (both
> branches): http://article.gmane.org/gmane.comp.gnu.libtool.general/7083

The problem is the new HPPA support isn't in the GCC or Sourceware trees.

However, I'm beginning to think the HPPA support for shared libraries
is totally wrong (i.e., linking in dependent shared libraries in shared
links).

First, see the recommendations in <http://docs.hp.com/en/1896/pthreads.html>.
HP libc contains stubs for the pthread stubs.  So, for example, when we link
libstdc++ against libc, we end up with the following dependencies:

-bash-2.05b$ chatr libstdc++.sl
libstdc++.sl:
         shared library
         shared library dynamic path search:
             SHLIB_PATH     disabled  second
             embedded path  enabled   first  /opt/gnu/gcc/gcc-4.1.0/lib
         internal name:
             libstdc++.sl.6
         shared library list:
             dynamic   /usr/lib/libm.2
             dynamic   /test/gnu/gcc-4.1/objdir/./gcc/libgcc_s.sl
             dynamic   /usr/lib/libc.2

So, libstdc++.sl is linked against the pthread stubs in libc
instead of the real pthread functions in libpthread.  I'm not sure
I fully understand how binding affects symbol resolution.  The
default binding is deferred, and in that case function references
are trapped via the linkage table and bound on the first reference.
If the first pthread reference comes from libstdc++, I think the
application will bind to the pthread stub functions in libc.  On
the other hand, if the first reference comes from from some other
place it may bind against routines in libpthread.  Thus, the default
binding with the current scheme is likely unpredictable or may change
as libraries load.

Linking dependent libraries into shared libraries also makes it
more likely that multiple incompatible versions would be used in
an application.  I don't think you will find any HP shared libraries
that have similar dependencies.

I've recently been trying to get Java working under HP-UX and haven't
yet found a version of gdb that can handle backtraces correctly because
they all get the shared library locations wrong.  This is probably
because the dynamic loader is loading multiple versions of a library.

I think a better approach would be to not link in any dependent
shared libraries in shared links.  As far as I can tell, there
aren't any issues with undefined symbols (at least in HP-UX 11).

Thoughts?

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472