Re: lt_dlopen an uninstalled library

[Bob Friesenhahn]

On Mon, 22 Nov 2021, ilya Basin wrote:

> Hi List.
> I'm making a program with plugins as shared libraries and when I run `make 
> check` I want my program to load the uninstalled plugins using lt_dlopen().
>
> I expected that passing `-dlopen libname.la` to libtool would force 
> the generation of a wrapper script setting the proper 
> LD_LIBRARY_PATH (just like regular linking with a shared .la does). 
> However, an ELF binary is generated and and attempt to call 
> lt_dlopen("libname.la") fails with "File not found". It only 
> succeeds if the filename contains "./.libs/". What am I doing wrong?

I am not sure what the correct answer is.  Normally loadable modules 
do not have "lib" prefixes and so normally one does not use a "lib" 
prefix in conjunction with -module.  Use of "lib" prefixes is for 
shared libraries indended to be linked with using a linker (for 
software compilation).

When libtool builds shared libraries and modules, it puts them in a 
".libs" subdirectory.  The ".la" file in the build directory should be 
enough for libltdl to load the module from the hidden ".libs" 
subdirectory.  When the module is installed, the a new ".la" file is 
created which is correct for the installed form, and the module may be 
re-linked while being installed.

Feel free to look at GraphicsMagick (http://www.GraphicsMagick.org/) 
source code for ideas.  GraphicsMagick uses lots of modules and its 
test suite works without installing the software.  It does not use 
libltdl's static-module "preloaded" feature.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt