Hello David, * David Everly wrote on Tue, Sep 12, 2006 at 02:11:16PM CEST: > On 9/12/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > >* David Everly wrote on Tue, Sep 12, 2006 at 01:02:47AM CEST: > >> > >> HP-UX B.11.23 U ia64
> >> Libtool is creating a script that wrappers the non-installed foo, and > >> sets the LD_LIBRARY_PATH accordingly _except_ that there is no > >> reference to the installed non-libtool-created library paths. > > > >Are you speaking about the case with -R/some/path or without? > > Yes, the ones using -R/some/path don't find themselves with > corresponding entries to LD_LIBRARY_PATH in the wrapper script. Ah yes, on HP-UX/IA shlibpath_overrides_runpath=yes, unlike on HP-UX/PA. > >If with, then why does it not work out of the box, i.e., without > >having to amend LD_LIBRARY_PATH? > > The reason I found this, is that someone had inadvertently set > LD_LIBRARY_PATH to an older version of the library in a different > directory. During our build we need to run the executable from the > build directory, and since they had LD_LIBRARY_PATH set, it superseded > the -R/some/path, and this caused failure. Yep. OK, I think I understand. IIRC some of these failures are fixable, and some are not (easily portably fixable). I need more information in order to decide which class yours belongs to. > This alone, does not make me think there is a libtool bug, but the > fact that paths are inconsistently added to LD_LIBRARY_PATH does. This suggests that this one could be fixable (since libtool does not decide avoidtemprpath=yes). But say, you also link to uninstalled libtool libraries, right? > Looking in the wrapper script, I noticed that, even though chatr of > the actual executable showed similarly hard coded paths to both the > libtool-created libraries as to the -R/some/path ones, there was the > inconsistency the -R/some/path entries not being present in > LD_LIBRARY_PATH. 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. > On our HP system, it might even be argued that the wrapper script > should ensure that LD_LIBRARY_PATH is not set so that all the paths > compiled in by libtool can be honored. Oh. Well, then all those people would start crying that installed proprietary compilers which themselves force the user to set LD_LIBRARY_PATH to some given value so that the compiler-provided libraries are found at runtime. > >(I don't deny that there could be a bug; if there is, then we should add > >a test case to expose it, and fix it.) > > I suppose a test case would be to build and install (not to the system > path) a libtool library and a non-libtool library to mutually > exclusive paths. Then use libtool to link an executable to both > shared libraries. 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? (I'll try to come up with a test then, or if you feel adventurous, feel free to do so too, preferably an Autotest style test for the CVS HEAD version of Libtool.) Cheers, Ralf _______________________________________________ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
