Re: hardcode_minus_L on HP-UX 11.23/IA-64

[Albert Chin]

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)