Problems with collect2 on hpux

[Warren_Baird]

Hi all,

I'm running into a strange problem on HPUX 11i with gcc-3.4.2 that I think 
is related to collect2. 

For anyone who isn't familiar with it, HPUX has some interesting 
peculiarities when working with 32 bit executables - they use SHLIB_PATH 
instead of LD_LIBRARY_PATH, and, to make things more interesting, the 
linking and loading system ignores SHLIB_PATH unless you pass the +s flag 
to the linker.  By default any shared libraries you create will only work 
if shared libraries they reference are in exactly the same path as they 
were when the shared library was created.I've had to rebuild the 
libstdc++.sl with the -Wl,+s flag so that it can find libgcc_s.sl from the 
SHLIB_PATH.

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. 

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

Has anyone seen anything like this before?   Any suggestions on how I 
might resolve it? 

Warren

Re: Problems with collect2 on hpux

[Warren_Baird]

"John David Anglin" <[EMAIL PROTECTED]> wrote on 06/11/2005 12:39:32
PM:

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

Nope - you are right - collect2 was a red-herring.

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

Yeah, I had to fix that problem first by going into the libstdc++ dir, and
doing a "make clean ; make LDFLAGS=-Wl,+s"

Wouldn't it make sense to do this by default?  Should I submit a patch to
do that?

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

It's not clear to me why relinking is required, if the -Wl,+s flag is used
everywhere...

I took a closer look at my libraries with chatr, and determined that the
problem was a thirdparty lib we were using that wasn't getting compiled
with -Wl,+s - and to make matters worse, was explicitly adding the full
path to libstdc++ on the link line - once I resolved those problems the
troubles went away.

Thanks for your help.

Warren