[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Thread Plug-in Support #2
From: |
Rob Browning |
Subject: |
Re: [PATCH] Thread Plug-in Support #2 |
Date: |
12 Apr 2001 12:41:10 -0500 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
NIIBE Yutaka <address@hidden> writes:
> +# libguileqthreads.so versioning info
> +LIBGUILEQTHREADS_MAJOR_VERSION=0
> +LIBGUILEQTHREADS_MINOR_VERSION=0
> +LIBGUILEQTHREADS_REVISION_VERSION=0
> +LIBGUILEQTHREADS_VERSION=${LIBGUILEQTHREADS_MAJOR_VERSION}.${LIBGUILEQTHREADS_MINOR_VERSION}.${LIBGUILEQTHREADS_REVISION_VERSION}
Ahh. You beat me to it :> I've had patches to version
libguileqthreads and libguilereadline for a while (had to have them
for Debian), but hadn't had a chance to integrate them yet (and hadn't
had my FSF paperwork done yet).
Questions for everyone:
(1) I think last time I talked about this (on guile-devel I
believe?), we'd planned to just version these libs with the same
numbers as libguile for now. Is that still appropriate? It
seems likely not, but if not, then does anyone have any problem
with starting off the "sub-libs" with the same major/minor
numbers as libguile? Otherwise we'll have a compatibility
problem, at least with Debian since there we already have
libguilereadline.9.0.0 and libguileqthreads.9.0.0.
(2) If we're not already, should we consider using libtool's rules
for choosing the shared library version numbers since we're
using libtool to build guile? (Search for "Libtool's versioning
system" in the libtool info pages.) We should proabably at
least make sure our strategy is compatible with libtool's (and
from looking at RELEASE, I suspect it is, though our method
isn't as sophisticated). If we do want to move to the strategy
libtool advocates, we'll need to update RELEASE and start using
AGE, etc.
(3) Should libguilereadline be versioned as well -- more
specifically, what did we decide about module .so files? Are we
just going to put them in /usr/lib/guile, or just in /usr/lib,
or what? I'm actually shifting back to think maybe we need an
arch-dependent parallel to %load-path that we use to find libs
for dynamic-link, something like '("/usr/lib/guile"
"/usr/local/lib/guile" ..). I *don't* think that dynamic-link
should search it automatically, but rather we should do
something like:
(let ((lib-path (find-in-path %dlib-path somelib.so")))
(if lib-path (dynamic-link lib-path ...)))
This allows similar flexibility for shared libs that we now have
for modules.
I also wonder if modules that dynamic-link to shared libraries
should generate and refer to explicit versions -- otherwise
things could be a mess in the future. Something like:
(let ((lib-path (find-in-path %dlib-path "somelib.so.5.3")))
(if lib-path (dynamic-link lib-path ...)))
Thanks
--
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930
- [PATCH] Thread Plug-in Support #2, NIIBE Yutaka, 2001/04/10
- Re: [PATCH] Thread Plug-in Support #2,
Rob Browning <=
- Re: [PATCH] Thread Plug-in Support #2, NIIBE Yutaka, 2001/04/12
- Re: [PATCH] Thread Plug-in Support #2, Marius Vollmer, 2001/04/12
- Re: [PATCH] Thread Plug-in Support #2, Rob Browning, 2001/04/12
- Re: [PATCH] Thread Plug-in Support #2, NIIBE Yutaka, 2001/04/12
- Re: [PATCH] Thread Plug-in Support #2, Rob Browning, 2001/04/13
- Re: [PATCH] Thread Plug-in Support #2, Marius Vollmer, 2001/04/13
- Re: [PATCH] Thread Plug-in Support #2, Rob Browning, 2001/04/13
- Re: [PATCH] Thread Plug-in Support #2, Rob Browning, 2001/04/14
- Re: [PATCH] Thread Plug-in Support #2, NIIBE Yutaka, 2001/04/13