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

[rm]

On Wed, Apr 24, 2002 at 09:33:33AM -0500, 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'd say "follow the masses". What  do applications like Apache, Perl,
Python etc. do? They all come with their 'private' locations for
application specific libraries (let's call them plug-ins, since this
seems to describe their function).
Why is manipulation of an _applications_ LD_LIBRARY_PATH an un-
acceptable behaviour (only applications exec'ed by guile would 
notice this, anyway) ?
 
> Also, you do have to worry about distribution packaging systems --
> make sure that everyone's going to be ok, inter-package
> dependency-wise with us placing libs in non-standard locations.

Again, it doesn't seem to be a problem in other languages that support
FFI. One _major_ benefit would be the possibility to have multiple versions
of guile not interfere with each other. As an example:
 i currently have both /usr/lib/python1.5, /usr/lib/python2.0 and
 /usr/lib/python2.1 on my box. Trying to do the same with guile turned
 out to be rather complex.

 Ralf Mattes