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
bfrie...@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
