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

[rm@fabula.de]

On Thu, Sep 19, 2002 at 10:02:25AM -0500, Rob Browning wrote:
> rm@fabula.de 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.

Yes, that's true, but i consider this a problem on a higher level: there
_is_ a semantic to the order of places in the search path and guile can't
make decisions about that. 

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

Hmm, maybe we need a clearer/cleaner distinction between extensions and
libraries that other apps are supposed to link against? The code i've written
so far always was meant to extend guile or the guile interpreter embedded in
an application. I can't really see why any application needs to link against
libguilelibxml2.so or libguilegtk-1.2.so.0.

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

For me that sounds like a good reason for making these two things separate
issues by using different code.

 Thanks for all the feedback

   Ralf


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