Re: lt_dlopen an uninstalled library

[ilya Basin]

> Loading modules is an extremely security-sensitive issue so it makes sense to 
> require that the specified path be absolute

I agree. Actually I haven't told the whole truth. My goal was to [mis]use 
libtool to load dynamically a regular library that is supposed to be in 
/usr/lib/ on Unix and at the same folder as .exe on Windows. The reason I don't 
link with it is my library depends on some other libraries that are not in the 
search path and my executable loads them first, then loads my library. This is 
why a wrapper script would solve it.

It would be gread if an option existed in libtool to force a wrapper script 
even if we don't link with any uninstalled libraries.

On 25.11.2021 2:15, Bob Friesenhahn wrote:
> On Thu, 25 Nov 2021, ilya Basin wrote:
> 
>> 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.
> 
> It is interesting that this is what was causing problems for you. Loading 
> modules is an extremely security-sensitive issue so it makes sense to require 
> that the specified path be absolute, or written like ./foo.la.
> 
> Regardless, GraphicsMagick does some things differently than perhaps the 
> original libtool/libltdl objectives since it tries not to be too dependent on 
> libltdl and it has its own module loader smarts.
> 
> Bob