[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: hardcode_minus_L on HP-UX 11.23/IA-64
From: |
Albert Chin |
Subject: |
Re: hardcode_minus_L on HP-UX 11.23/IA-64 |
Date: |
Fri, 4 Nov 2005 12:19:39 -0600 |
User-agent: |
Mutt/1.5.6i |
On Fri, Nov 04, 2005 at 05:38:20PM +0100, Ralf Wildenhues wrote:
> * Albert Chin wrote on Thu, Nov 03, 2005 at 04:09:03AM CET:
> > >From ld(1) on HP-UX 11.23/IA-64:
> > +[no]defaultrpath
> > +defaultrpath is the default. Include any paths
> > that are specified with -L in the embedded path,
> > unless you specify the +b option. If you use +b,
> > only the path list specified by +b is in the
> > embedded path.
> >
> > The +nodefaultrpath option removes all library
> > paths that were specified with the -L option from
> > the embedded path. The linker searches the
> > library paths specified by the -L option at link
> > time. At run time, the only library paths
> > searched are those specified by the environment
> > variables LD_LIBRARY_PATH and SHLIB_PATH, library
> > paths specified by the +b linker option, and
> > finally the default library paths.
> >
> > So, hardcode_minus_L=yes is incorrect on this platform if
> > +nodefaultrpath is in LDFLAGS.
>
> ACK. Or when we put at least one +b in the command line.
> Hmm, when creating a library, we use +b anyway.
Yes. But, if the LDFLAGS="-L[path]", we're screwed without
+nodefaultrpath. I've submitted a patch so that on ia64*, we use
+nodefaultrpath when creating libraries.
> Is it guaranteed that we already use -L for each directory in question
> when creating a program? Ie., there don't appear any +b, right?
>
> > Should we set hardcode_minus_L=yes only
> > when there is no +nodefaultrpath (similar to how we set
> > aix_use_runtimelinking=yes when LDFLAGS has -brtl in it)?
>
> Probably a good idea. Do you have access to HP-UX 11 (how about 9, 10?)
> to test?
11.23/PA ld(1) doesn't document +nodefaultrpath, 11.00/PA documents it
for 32-bit SOM, and 11.11/PA documents it for 64-bit ELF. Probably a
new feature that requires an updated linker patch.
> > We should probably do this only when the compiler and linker driver
> > are the same.
>
> Erm, why? Where does the compiler driver come into play here?
Forgot what I was thinking here :)
--
albert chin (address@hidden)