Re: lt_dlopen an uninstalled library

On Thu, 25 Nov 2021, ilya Basin wrote:

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

Years ago, Gary V. Vaughan (a key libtool developer) suggested to me 
that dlopen() is quite portable across Unix-like systems (even Apple's 
OS X) and that libltdl is not really necessarily needed in order to 
load dynamic modules/modules.  This leaves Microsoft Windows for which 
it it is relatively easy to use its similar facilities via 
LoadLibrary()/FreeLibrary().

It is true that libltdl will help on systems where library 
dependencies do not work properly, or where special compiler options 
must be used, and it can be used to emulate a loadable module in 
static builds.

Libtool is exceedingly helpful when it is desired to be able to 
support static builds and it also helps for compiling shared libraries 
(DLLs) under Microsoft Windows.

So it is worth considering using dlopen() directly.

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