Re: lt_dlopen an uninstalled library

2021-11-24 Thread Bob Friesenhahn

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
--
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



Re: lt_dlopen an uninstalled library

2021-11-24 Thread ilya Basin
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 0x773cc8 In: OpenModule  L1422 PC: 0x77e7bc6c 
(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