Re: 1.6.0 problems with libguilereadline-v-12 and fix

[Rob Browning]

Greg Troxel <address@hidden> writes:

>    dlopening does not use this link-time binding.  (perhaps on NetBSD
>    the -R values are being used by dlopen

Likely for loading inter-linked libraries, but I'd guess not for the
initial top-level dlopen.

> 2) On BSD ELF systems, it is my opinion that having to have set
>    LD_LIBRARY_PATH is a sign of underlying brokenness.  I have not had
>    to do this other than guile.  So it's a warning sign that guile
>    seems to require setting this variable.

You don't have to do that if you install an app to /opt/foo?  I think
part of the problem here is that libltdl's failure to match ld.so's
behavior is exposing the "special nature" on most systems of
/usr/local.

> 4) Setting LD_LIBRARY_PATH can't work in general.   If one had two
>    guile installations in /usr/guile16-{foo,bar}, one of the lib dirs
>    has to come first.  The other installation will dlopen the wrong .so
>    files.

Yes, though that's what you'd expect under the traditional unix model.
You can't have two versions of the same app installed in different
locations and expect to select which one you want to run without
changing any of your environment variables (or other configuration
bits).  I tend to doubt most people are going to need to have (and
switch between) multiple copies of the same version of guile, and
those that do, are probably developers and can write up a little
"guile-env" script that lets you run whichever you want "guile-env
1.5.7 guile --version", etc.

This "multiple copies problem" exists with *any* app that includes its
own shared libraries.  Granted the -rpath mechanism does fix it in
some sense, but if we don't respect the standard
LD_LIBRARY_PATH/ld.so.conf mechanism, are we sure we don't end up
(even if only on some platforms) with strange multiple-version linking
problems for apps that link to a set of libs that have their own
interdependencies?  Put another way, how do we make sure that apps
built at different points in time against libs with their own
interdependencies don't end up runtime linked against multiple
versions of libguile, or libguile-srfi-*?  With the
LD_LIBRARY_PATH/ld.so.conf setup, it's clear.  There's only one
possible choice at runtime.  It's it also clear if everything uses
-rpath?  Can two different libraries have -rpaths pointing to two
different copies of the same sub-library?

I'm not sure this is a serious problem, and perhaps just mandating the
use of guile-config fixes it, but it's something I think we should
consider.

> 5) LD_LIBRARY_PATH doesn't work in setuid/setgid situations.  Guile
>    should not foreclose this option.

Interesting point I hadn't thought about.

> In general, I think the -R concept for shared libraries has been a
> big win - library locations get bound into the dynamic executable,
> rather than having system changes over time cause libraries in
> different directories to get loaded.  So I freely admit that this
> biases my opinions.

Hmm, well at least in the past (and perhaps still), debian policy
forbid --rpath (I presume the same as -R).  As I recall, the reasoning
for this was that from a system integrator's perspective, using an
rpath causes major problems.  Libraries will need to be moved around
from time to time and if you use rpath, you make it impossible to do
this transparently/incrementally.

And for those who haven't considered (or don't remember), it's not
true that guile's libs are only intended for guile's consumption.  It
is a stated design goal that other apps should be allowed/encouraged
to link directly against guile's libraries, that includes libguile,
libguile-srfi-srfi*, etc.  Apps should be able to use
scm_make_u8vector (), and this means that they have to be able to link
against the library.  So we have to consider our decisions in that
context.

(Come to think of it, given the above, there's a big bug in 1.6.0 --
 none of the srfi.h headers are publically installed...)

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