Re: [d.love@dl.ac.uk: dynamic loading of native code modules]

[Rob Browning <rlb@defaultvalue.org>]

rm@fabula.de writes:

> 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) ?

Aside from hearing people claim that "it's for user use only", I think
one of the primary issues was with whether or not you put the
additions at the beginning or the end -- i.e. do you allow the user to
override your value for debugging purposes, etc?  Another complaint if
I recall correctly is that if you're inserting directories that aren't
very *specific* you can cause other unwanted libs to be pulled in.
i.e. inserting /usr/local/lib somewhere might be *bad*, but if we were
only inserting /usr/lib/guile/1.8/ then that concern would be somewhat
alleviated.

One other concern would be what to do about add-ons -- i.e. you'd have
to be careful to work out a strategy whereby things like guile-www,
guile-pg, etc would have a place to put their libs that guile could
find.  Further, what if guile ships with a version of something like
guile-pg built in, but now then user wants to use a new version of
guile-pg.  If we aren't careful, i.e. if we just append
/usr/lib/guile/1.8 to the front of the LD_LIBRARY_PATH to be safe,
we've now prevented the user from loading their newer version unless
they install it in a way that clobbers the one inside the guile
install dir, a no-no as far as most distributions are concerned.

I can't recall off the top of my head if there are any stronger
arguments against it.

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

Guile has planned to allow users to link directly against guile's
internal libs, i.e. the user is supposed to compile an app and link
against -llibguile-srfi-srfi-4 if they need that functionality[1].  I
was under the (possibly mistaken) impression that python and perl
didn't intend to support that, and if not, that affects how much
flexibility you have.  [1] i.e. other apps are supposed to be able to
link appropriately and then call scm_make_u8vector directly.  Bear in
mind that allowing direct linking also means that you have to fully
version all your shared libs in the traditional manner.  This is
complex, but does have a number of benefits, including being well
understood on the OS side and allowing, if the distributions packaging
guile handle things right, easy upgrades of guile independent of all
the apps compiled against guile and it's various shared libs.

That said, I totally agree that when we sit down to work on versioning
scheme-level "use-modules modules", and on a better solution to the
current situation wrt lt_dlopen and versioned shared libs, we should
survey what the other languages are doing as part of the process.

It may well be that the subdirectory approach is suitable, and in fact
its one I originally leaned toward, but I was shifted away after
talking to Marius about direct linking and realizing that if we were
going to properly version all our shared libs to accmodate  etc.

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

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel