[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lt_dlopen an uninstalled library
From: |
Bob Friesenhahn |
Subject: |
Re: lt_dlopen an uninstalled library |
Date: |
Wed, 24 Nov 2021 17:15:09 -0600 (CST) |
User-agent: |
Alpine 2.20 (GSO 67 2015-01-07) |
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
bfriesen@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, Roumen Petrov, 2021/11/23