Re: address@hidden: dynamic loading of native code modules]

[Lynn Winebarger]

On Wednesday 24 April 2002 09:33, Rob Browning wrote:
> Thien-Thi Nguyen <address@hidden> writes:
> 
> > well i raised this point two (3?) years ago and the counter-point
> > was that all shared object libraries are the same and should be
> > treated the same.  of course, this is not entirely true; all the
> > object libraries we're interested in playing w/ via a scheme
> > interface must depend on libguile, minimally, and are loaded into a
> > more restricted environment than say "appfoo dynloads libbar.so".
> 
> And if we put them in some non-lib dir, do you propose that we
> internally mangle the user's LD_LIBRARY_PATH in order to allow ldso to
> find the libs?  Many people consider this unacceptable application
> behavior, so that's another point that somewhat weighs in favor of
> using the standard directories.

      I don't think this is exactly accurate.  The documentation I have for 
libltdl states (note the "in the order as follows"!):
    
     If libltdl cannot find the library and the file name FILENAME does
     not have a directory component it will additionally search in the
     following search paths for the module (in the order as follows):

       1. user-defined search path: This search path can be set by the
          program using the functions `lt_dlsetsearchpath' and
          `lt_dladdsearchdir'.

       2. libltdl's search path: This search path is the value of the
          environment variable LTDL_LIBRARY_PATH.

       3. system library search path: The system dependent library
          search path (e.g. on Linux it is LD_LIBRARY_PATH).

     Each search path must be a colon-separated list of absolute
     directories, for example, `"/usr/lib/mypkg:/lib/foo"'.

     If the same module is loaded several times, the same handle is
     returned.  If `lt_dlopen' fails for any reason, it returns `NULL'.

which means you have 2 ways of searching that won't mess with normal
shared library behaviour.  Although it does look as though it won't play 
well when linking to library/application that uses libltdl for its own modules. 
You'd have to work around it by having a wrapper function switch the 
paths back and forth, and beware threads.  

Lynn