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

[Marius Vollmer]

address@hidden writes:

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

When we can offer our libraries to "many different" applications, why
shouldn't we do it?  Guile is not foremost an application, it _is_ a
library that is meant to be used by many different applications.  It's
'extensions' (like libguilereadline, libguile-srfi-* or libguilegtk)
are in the same category.

>    I think one can reduce this discussion to the question: "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?" I tend to favour the second view.

It is a normal shared library.

I frankly don't see any problem with that except that people seem to
insist on installing Guile in non-standard places but refuse to
configure their system to recognize these non-standard places.

(An additional problem that unfortunately obscures the situation is
that libltdl is somewhat buggy and doesn't yet completely implement
what we want from it.  I hope that once this is fixed, the picture as
I see it will be clearer to others as well.)

> Modifying the environment will affect the linking behaviour of the
> application as a whole _and_ will change the linking behaviour of all
> child processes -- not really an option for many uses.

Why not?  Are you afraid that the presence of the Guile libraries in
the search path will harm other code?

> > Marius has suggested that perhaps the right thing to do is discuss
> > this with the libltdl people and see if we can settle on a more
> > general solution, one that might also involve a versioned
> > lt_dlopen.  I'm inclined in that direction as well.
> 
> Yes, i think this is a good idea (and, given the number of problem reports
> in this list alone, probably needs to be done soon).

We will 'fork' libltdl for Guile and fix it for our use.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405