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: Gary Houston
Subject: Re: 1.6.0 problems with libguilereadline-v-12 and fix
Date: 22 Sep 2002 19:52:57 +0100

> From: Greg Troxel <address@hidden>
> Date: 20 Sep 2002 08:04:22 -0400

> I think my real points are
> 
> 1) There is an important class of systems and reasonable user behavior
>    (BSD with odd prefixes, at least) where guile works fine except for
>    the dlopening of guile's internal support libraries.
> 
> 2) It is always the right thing for guile to open the library in
>    exactly the installed path.  (If not, scheme files like ice-9/foo
>    should be searched for in the same way - it makes no sense to do
>    these differently, and without a complete solution you can't unpack
>    a built guile someplace else.)

I think you are right about this, more or less.  I think guile should
always pass a full path when dlopening.  However, like the case for
scm files, I think Guile should have its own search path for shared
objects, i.e., an equivalent to %load-path which a user can set.

While Marius is not around, I think his argument against this is that
libguile should not take over functionality from libtool, i.e.,
libtool's "standard" searching should always be used, and any problems
should be addressed by improving libtool.  Improvents to libtool could
give benefits to other non-guile applications perhaps.

However I don't like the requirement that every module needs to be
versioned correctly, which seems unlikely to go away even if libtool
is improved.  I also don't like the idea of adding large numbers of
guile modules to standard library directories in the default
installation.

As for linking from C applications, it seems cumbersome to require
that they use -l for each module.  Only primitive Scheme procedures
can be called directly as C functions and this goes behind the back of
the module system, possibly leading to naming conflicts.  I don't
think anyone is suggesting that a Guile module would ever be linked by
an application without also linking libguile, so it seems to me that
no extra dependency is introduced if libguile mediates all access to
modules, also for C code (i.e., if you want to call a primitive module
function from C, ask libguile for a handle to it first).





reply via email to

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