Re: automake/libtool question
* 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 Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: automake/libtool question
On 9/12/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: 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? Yes, in my case, I am linking to uninstalled libtool libraries, and these are both hard-coded (revealed by chatr) and added to LD_LIBRARY_PATH in the wrapper script--which is why I'm thinking the fix I would like (admittedly uninformed of the issues on all other supported systems) is to go ahead and add the additional -R of non-libtool library paths to the wrapper script's LD_LIBRARY_PATH as well. > 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. Ah, so it sounds like I could do something like the following for now: ./configure shlibpath_var=/my/rpath > 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? Pulled in through some uninstalled libtool library. As I'm coming to understand this would certainly be a corner case. (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
Re: automake/libtool question
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
Re: automake/libtool question
[ Cc:ing both lists; let's drop the automake list ] Hello David, * David Everly wrote on Tue, Sep 12, 2006 at 01:02:47AM CEST: > > HP-UX B.11.23 U ia64 > automake (GNU automake) 1.9.6 > autoconf (GNU Autoconf) 2.60 > ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) > For the installed, libtool-created libraries, I am use "-L/some/path" > in foo_LDFLAGS when linking foo, but I seem to need to use both > "-L/some/path" _and_ "-R/some/path" when linking foo with installed > non-libtool-created libraries. Yes, I think this is intended, although I admit that the documentation doesn't reveal this. (Old old convention.) > 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? If with, then why does it not work out of the box, i.e., without having to amend LD_LIBRARY_PATH? (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.) Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
