[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lt_dlopen an uninstalled library
From: |
ilya Basin |
Subject: |
Re: lt_dlopen an uninstalled library |
Date: |
Thu, 25 Nov 2021 01:13:29 +0300 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 |
Hi Bob. I configured the GM build with '--with-modules', ran `make check`
successfully. Then truncated the built .so files inside the 'coders/' dir to
break it. Then reproduced the failure in gdb
[il@reallin GM]$ export
MAGICK_CONFIGURE_PATH='/home/il/builds/GM/config:/home/il/builds/GM/config'
[il@reallin GM]$ export MAGICK_CODER_MODULE_PATH='/home/il/builds/GM/coders'
[il@reallin GM]$ gdb --args ./tests/.libs/lt-constitute -storagetype char
/home/il/builds/GM/tests/input_truecolor.miff bgr
So it turned out that the test program relies on the full path to the modules
dir passed to the program and it calls lt_dlopen() with the full path. I guess
I'll have to set the test environment in Makefile.am. Thanks.
┌─magick/module.c──────────────────────────────────────────────────────────────┐
│ 1419 (void) LogMagickEvent(ConfigureEvent,GetMagickModule(), │
│ 1420 "Opening module at path \"%s\" ...", path); │
│ 1421 │
│ > 1422 handle=lt_dlopen(path); │
│ 1423 if (handle == (ModuleHandle) NULL) │
│ 1424 { │
│ 1425 FormatString(message,"\"%.1024s: %.1024s\"",path,lt_dlerror│
│ 1426 ThrowException(exception,ModuleError,UnableToLoadModule,mes│
│ 1427 return(MagickFail); │
│ 1428 } │
│ 1429 /* │
└──────────────────────────────────────────────────────────────────────────────┘
multi-thre Thread 0x7ffff73cc8 In: OpenModule L1422 PC: 0x7ffff7e7bc6c
(gdb) print path
$1 = "/.snapshots/persist/builds/GM/coders/miff.la\000\000\000\000\313|VUUU\000\
(gdb)
On 23.11.2021 20:31, Bob Friesenhahn wrote:
> 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
Re: lt_dlopen an uninstalled library, Roumen Petrov, 2021/11/23