bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: automake/libtool question


From: David Everly
Subject: Re: automake/libtool question
Date: Tue, 12 Sep 2006 06:11:16 -0600

Thank you for responding Ralf,

On 9/12/06, Ralf Wildenhues <address@hidden> wrote:
[ 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?

Yes, the ones using -R/some/path don't find themselves with
corresponding entries to LD_LIBRARY_PATH in the wrapper script.

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.

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.

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.

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.

(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.


Cheers,
Ralf





reply via email to

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