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

[Rob Browning]

Lynn Winebarger <address@hidden> writes:

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

Ahh, I had forgotten about that.

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

And AFAIK adding a path via the lt_dl*search* functions above wouldn't
help other apps or app libs that are directly (i.e. ldso, not libltdl)
linked against the guile libs.

BTW thanks for the lt_dl*search* reminder.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD