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: Rob Browning
Subject: Re: 1.6.0 problems with libguilereadline-v-12 and fix
Date: Sun, 22 Sep 2002 20:50:48 -0500
User-agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu)

Gary Houston <address@hidden> writes:

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

Well, that's certainly a possiblity, but when I started working
on/thinking about the "add-on library" issue and was trying to
ascertain what features of the shared libraries were optional and what
features were required, I was told that the ability to use the public
functions provided by these libraries directly from other C
applications and libraries without any indirection was a *required*
feature.  Accordingly all my considerations and responses since have
been with that requirement in mind.

If we *did* allow a level of "patchup" (or indirection) at runtime,
such that -l linking was no longer permitted, then that would change
the design landscape substantially...

Say

  scm_c_use_module ("foo bar",
                    "bar-1", &bar_1_func,
                    "bar-2", &bar_2_func,
                    NULL);

or whatever.

*Should* we do this?  I don't know -- this is probably something
Marius needs to comment on, though as I mentioned above, in the past I
believe the answer has been "no".

On a more general note, though I won't actually be out of town for the
next two weeks like Marius, I may in fact be fairly slow on the lists.
I have some real-world items that will be keeping me very busy, and
the free time I do have I really need to spend fixing up some
languishing Debian issues, including packaging 1.6.  I also want to
finish up re-integrating my GMP bignum work into the latest CVS.

With respect to shared libraries, I'm tempted to suggest we table the
discussion until Marius can participate.

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




reply via email to

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