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

[Rob Browning]

address@hidden writes:

> May i point at similar sugestions i posted a while ago ;-) Libltdl
> does provide API calls to modify the search path at runtime.  Why
> don't we extend dynamic linking like this:

That has the same fundamental problem as setting LD*_LIBRARY_PATH
unless we only modify the value briefly, and *every* time we call
lt_dlopen (still an interesting suggestion).

The problem is that other libraries (or the app linking against
libguile itself) may also put their directories in there, and if, for
example, even one of them puts "/usr/local/lib" at the front after
you've made your modifications, and if there's another "incorrect"
version of some part of guile in /usr/local/lib, then you're likely to
be in trouble the next time you call lt_dlopen.

>  - Putting things in a standard place, or, like Marius phrased it:
>    "The right thing is to configure your system so that the installed 
>     libraries are visible to all programs, in the standard way."
>    I can't agree here -- those standard places are meant for libraries
>    that can and will be shared by many different applications.

But libguilereadline is the *only* library for which this isn't the
case.  The rest are publically available and it apps are expected to
link directly against them. 

>    "what's the true nature of code linked dynamically 
>    from guile - is it a normal shared library or is it rather a 'plug-in'
>    meant to extend an application?"

As it stands now, the answer is "both".  That's one of the main
reasons this problem is hard.

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