guile-devel
[Top][All Lists]
Advanced

[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



reply via email to

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