This is the mail archive of the
mailing list for the GCC project.
Re: Problems with collect2 on hpux
- From: Warren_Baird at cimmetry dot com
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 14 Jun 2005 15:21:57 -0400
- Subject: Re: Problems with collect2 on hpux
"John David Anglin" <firstname.lastname@example.org> wrote on 06/11/2005 12:39:32
> 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
> 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
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.