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

[Rob Browning]

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.

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.

> placing all these libguile-dependent thingies in libdir directly
> means we need to implement and enforce some kind of name flattening
> algorithm should the thingies be hierarchical instead of using an
> already existing file hierarchy organization (the filesystem
> hierarcy).  it also means we are subject to the vagaries of the
> thingy-access program (libtool).

It also means that we don't have to worry about name collisions.  If
you put all the libs in /usr/lib, then it's (filesystem wise)
impossible to accidentally have shadowing of one lib by another with
the same name and to have to deal with the mysterious errors that can
cause.

> these are points i should have stressed more at that time, but i
> guess when it comes to appreciating clutter, nothing beats
> experience...  so now that dealing w/ libraries has proven to be a
> royal nightmare, i'm hoping we can wake up and design the "guile
> object library" and its access protocols and reverse this stupidity.

Any reason you have to be both condescending and insulting about this?

Please feel free to post your obviously better solution, but don't
forget to make sure it works across all the supported architectures
and operating systems (I hear AIX is particularly nasty), both on the
build side and on the runtime side, and that it doesn't cause serious
packaging or dependency problems for any of the major distributions.

While I get fairly aggravated with libtool (and libltdl) myself from
time to time, I fully recognize the complexity of the problem they're
trying to solve.

Oh, and I'm not saying there isn't a better solution -- I'd be more
than happy to explore the possibilities, but I consider your
suggestion that "these people just chose this stupid solution because
they like to be stupid" disingenuous at best, and it certainly doesn't
inspire me, nor I suspect others, to want to work *with* you on the
problem.

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