libtool
[Top][All Lists]
Advanced

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

Re: Running an uninstalled executable


From: Alberto Luaces
Subject: Re: Running an uninstalled executable
Date: Wed, 13 May 2015 09:50:27 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Bob Friesenhahn writes:

> On Tue, 12 May 2015, Alberto Luaces wrote:
>
>> Hello,
>>
>> in an autoconf+automake+libtool C++ project containing only one program,
>> I want to run the executable before installing it.
>>
>> Reading the manual I thought that it could be done with
>>
>> libtool --mode=execute program_binary
>>
>> but it fails, since there are undefined references to shared libraries
>> not installed in standard directories.
>>
>> Can libtool solve this problem for me?
>
> Libtool is supposed to solve this problem automatically for libraries
> in the build-tree built using libtool, or involved libraries which
> have a correct associated ".la" file.  It is not uncommon for the .la
> files that libtool installs to be deleted, or for libraries to be put
> into a location other than the paths the .la file says they reside.
>
> If the installed libraries violate the libtool expectations, then
> there are only the choices of building the software with a hard-coded
> run-path (-RLIBDIR or -Wl,-rpath,/libdir'), or using environment
> variables like LD_LIBRARY_PATH.
>
> As a developer, I find using the run-path to be most
> reliable/convenient, but this may not be suitable when creating
> packaged binaries for installation.

Thanks, Nick and Bob.

So the key point is the existence of the .la files.

To sum it up, I would say:

* From a developer point of view, when having a test suite depending on
  libraries installed in non-standard places, LD_LIBRARY_PATH, -rpath
  and -R are suitable candidates.

* From an user point of view, when making tests with an uninstalled
  executables, it could be interesting to write those .la files by hand
  (seems easy!) in order for libtool to find them at link time.

The second point is an internal hack, I do not want to mean that it is a
suitable procedure for distribution purposes.

-- 
Alberto




reply via email to

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