This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems with collect2 on hpux







"John David Anglin" <dave@hiauly1.hia.nrc.ca> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]