guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: rm
Subject: Re: 1.6.0 problems with libguilereadline-v-12 and fix
Date: Thu, 19 Sep 2002 17:27:59 +0200
User-agent: Mutt/1.3.24i

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]