bug-libtool
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]