* David Everly wrote on Tue, Sep 12, 2006 at 04:05:34PM CEST: > On 9/12/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > > >Yep. If this one turns out to be non-fixable, we may just have to > >document that users may need to do both for linking against non-libtool > >libraries: add -R/some/path to LDFLAGS, and /some/path to > >$shlibpath_var. Not sure yet. > > Ah, so it sounds like I could do something like the following for now: > > ./configure shlibpath_var=/my/rpath
No, sorry. $shlibpath_var is (my nonobvious) shorthand notation for LD_LIBRARY_PATH. So currently you should document that the user should not set LD_LIBRARY_PATH pointing to old installed libs on HP-UX/IA. > >Is the executable in your test case linked directly to the installed > >non-libtool library, or is that dependency pulled in through some > >uninstalled libtool library? > > Pulled in through some uninstalled libtool library. As I'm coming to > understand this would certainly be a corner case. Nono, I think your report is fine. I'm trying to find out if (quoting `libtool --mode=link --help) this flag: | -R[ ]LIBDIR add LIBDIR to the runtime path of programs and libraries should cause Libtool to always add LIBDIR to $shlibpath_var (i.e., LD_LIBRARY_PATH in your case) in the wrapper for uninstalled programs on systems with shlibpath_overrides_runpath=yes (on systems where this is `no' there should be no point in doing so). I tend to think the answer is yes, except that I'm not sure yet this could cause regressions for other use cases. In any case, the only position this could be added is: - after the temprpath entries currently computed by link mode (because they point to uninstalled paths, which have to be preferred), - before the user-set value of LD_LIBRARY_PATH (so your use case is actually fixed). Currently I cannot think of a situation where this would cause a regression (except in corner cases that worked more or less "by pure luck" before anyway). I'll try to come up with a test. Thanks for the report! Cheers, Ralf _______________________________________________ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
