Re: lt_dlopen an uninstalled library
Bob Friesenhahn <[email protected]>
| Newsgroups | gmane.comp.gnu.libtool.general |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt