[Top][All Lists]
[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
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, (continued)
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Paul Jarc, 2002/09/20
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Thien-Thi Nguyen, 2002/09/20
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Paul Jarc, 2002/09/20
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Paul Jarc, 2002/09/20
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Thien-Thi Nguyen, 2002/09/20
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Paul Jarc, 2002/09/21
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Thien-Thi Nguyen, 2002/09/25
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, Gary Houston, 2002/09/22
- Re: 1.6.0 problems with libguilereadline-v-12 and fix,
Rob Browning <=