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 ([EMAIL PROTECTED]) _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
