[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: automake/libtool question
From: |
Ralf Wildenhues |
Subject: |
Re: automake/libtool question |
Date: |
Tue, 12 Sep 2006 15:02:43 +0200 |
User-agent: |
Mutt/1.5.13 (2006-09-01) |
Hello David,
* David Everly wrote on Tue, Sep 12, 2006 at 02:11:16PM CEST:
> On 9/12/06, Ralf Wildenhues <address@hidden> 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