"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
