Re: Search path for C libraries

[Vorfeed Canal]

On 10/18/05, Ludovic Courtès <address@hidden> wrote:
> Hi,
>
> Greg Troxel <address@hidden> writes:
>
> > Perhaps dynamic-link should look in guilelibdir _only_ if an absolute
> > path is not given, or a primitive that does this.  One important
> > feature is that inclusion, dynamic link, etc. should be able to ensure
> > it gets exactly what was searched for and tested at configure time.
>
> Right.  This is one of the concerns that was raised by Vorfeed Canal
> earlier I think.
>
Yup. This is EXACTLY why libltdl have search_path in first place. Of
course libltdl WILL NOT try to use this path if full path is given in
load-extension - this is all built in ltdl:
http://www.gnu.org/software/libtool/manual.html#Using-libltdl

In my patch I moved search_path to scheme level and when dynamic
loaded is used old ltdl search_path will be forgotten. Since guile is
designed to be used in big, complex programs perhaps its better to
save search path and then restore it. And this must be done under 
lt_dlmutex_lock/lt_dlmutex_unlock, obviously.

I left all this out of patch since this was proof-of-concept kinda
thing anyway and since before guile 1.8 release someone should do
something with this:

-- guile-1.7.2/libguile/dynl.c
/*
  From the libtool manual: "Note that libltdl is not threadsafe,
  i.e. a multithreaded application has to use a mutex for libltdl.".

  Guile does not currently support pre-emptive threads, so there is no
  mutex.  Previously SCM_CRITICAL_SECTION_START and
  SCM_CRITICAL_SECTION_END were used: they are mentioned here in case
  somebody is grepping for thread problems ;)
*/
-- cut --
Libtool manual does not say this anymore:
http://www.gnu.org/software/libtool/manual.html#Thread-Safety-in-libltdl
and guile DOES have support for pre-emptive threads now so it's good
idea to do something about this.

This is separate problem and there are not much to discuss: ltdl can
not be used in multi-threaded environment without
lt_dlmutex_lock/lt_dlmutex_unlock (it changes global variable
search-path internally, for example!) and while you can export ltdl's
variable to scheme level "as is" you'll be forced to export
LT_PATHSEP_CHAR as well and then every scheme module will be exposed
to gory details of OS dynamic loading mechanism (":" vs ";") so it all
will look quite ugly (barely better then current way of parsing and
changing of LD_LIBRARY_PATH/LTDL_LIBRARY_PATH).

> Maybe the right way to do this would in fact to have module developers
> generate the `dynamic-link' code at configure-time (using Autoconf
> substitution) in order to hard-wire the library path.

It can be done already, but most distribution's HOWTOs are quite vocal
about never using -rpath with C libraries - and this is the same
thing.

> Unfortunately, this isn't very elegant and it precludes, for instance, 
> running the
> module's test suite before installing it (because `dynamic-link' would
> either fail or load the wrong library).

This is one reason, yes.