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