Re: Problems with collect2 on hpux

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> The strange behaviour I'm seeing is that if I link my shared libraries 
> with -Wl,+s, then some of them work fine and find all of their libraries 
> based on the SHLIB_PATH settings.  However, some of my libraries find 
> everything *except* libstdc++.sl from the SHLIB_PATH  - these libraries 
> only load if I put libstdc++.sl in the exact same location it was in when 
> I built the library in the first place. 

The fundamental problem is the HP linker hardcodes paths into binaries.
This affects the way libtool does links and to a lesser extent the
prefix processing used by GCC.  When using the SOM linker, GCC always
strips dotdots from paths.  The downside of this is it causes problems
moving GCC after installation.

> My suspicion is that when collect2 relinks things it's not using the +s 
> flag, and that is causing the behaviour I'm seeing...

As far as I'm aware, collect2 doesn't strip linker options.  You can
see more details about the link process using -Wl,-debug and -Wl,-v.

The chatr program can show and change the dynamic path search.  It
also shows the library list.  If recall correctly, libraries linked
using -l have their full path hardcoded.  For example,

-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-3.4.4/lib
	 internal name:
	     libstdc++.sl.6
	 shared library list:
	     dynamic   /usr/lib/libm.2
	     dynamic   /xxx/gnu/gcc-3.3/objdir/gcc/libgcc_s.sl
	     dynamic   /usr/lib/libc.2

It's not very nice that the shared library list for libstdc++.sl
includes libgcc_s.sl in the GCC build directory.  I believe that the
HP dynamic loader first looks for it there.  If that doesn't work,
it strips off the basename of the library and tries the dynamic
search path.

The above is an example why executables and shared libraries need
to be relinked when installed on this target.  The problem with
libgcc_s.sl is that it isn't a "libtool" library.  As a result,
libtool doesn't know how to properly generate the dependencies for the
link used during installation (i.e., generate the correct sequence
of -L options).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)