> > static void *
> > sysdep_dynl_link (const char *fname, const char *subr)
> > {
> > - lt_dlhandle handle;
> > - handle = lt_dlopenext (fname);
> > + lt_dlhandle handle = NULL;
> > + SCM scm_search_path = scm_string_join (*scm_loc_load_path,
> > + scm_from_locale_string (":"),
> > + SCM_UNDEFINED/*scm_sym_infix*/);
> > + char * search_path = scm_to_locale_string (scm_search_path);
> > + scm_frame_free (search_path);
> > + if (!lt_dlsetsearchpath (search_path))
> > + {
> > + handle = lt_dlopenext (fname);
> > + }
>
> Will this still allow loading from the usual places as well?
>
Yes. http://www.gnu.org/software/libtool/manual.html#Libltdl-interface
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 changed by the
program using the functions lt_dlsetsearchpath, lt_dladdsearchdir and
lt_dlinsertsearchdir.
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).
In reality libltdl will search in user-defined search path first, then
in $LTDL_LIBRARY_PATH, then in $LD_LIBRARY_PATH, then in default path
(/lib then /usr/lib on linux), then finally in current directory. Good
from security viewpoint (of course from security viewpoint it'll be
the best to avoid current directory altogether, but.. we can not have
everything, right?).
> Conclusion: this looks OK to me, but I'm not an expert on this
> subject. I recall previous threads on why it is (or is not) desirable
> for all Guile libraries to go into /usr/local/lib or /usr/lib, but I
> can't remember what the arguments were.
I'm not talking about GUILE libraries. I'm talking about EXTENSIONS
libraries. While GUILE libraries for different versions of GUILE can
happily live in /usr/lib (they have different API versions) this is
NOT true for the extensions: their SO-number is related to API of the
EXTENSION, not GUILE but this library is linked to GUILE library as
well. Thus - collisions. It's possible to avoid this probloem with
some hacks but... it's really better to just supply extension-writers
with sane place DIFFERENT for different versions of GUILE.
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
