Re: Parallel installability with 1,3,4?

[Rob Browning]

Andy Wingo <address@hidden> writes:

> In short, the libraries are not parallel-installable. How do you
> propose to fix this?

> I really wish one could pass parameters to modules as they are used,
> e.g. version.

In the long run, we may enhance libguile-ltdl to support versioned
dynamic-link loading (as ld.so does), and we're also currently
inclined toward eventually adding versioned scheme modules (via
use-modules, etc.) to guile as well, but until then, the best solution
I know of is the one we've used in guile 1.7.

In guile 1.6 (and later) we put the soname (or something that changes
with the soname) into the name of every shared library we plan to
dynamic-link.  So we have

  /usr/lib/libguilereadline-v-12.so.12.3.0
  /usr/lib/libguile-srfi-srfi-13-14-v-1.so.1.0.0

etc.  So we can call (dynamic-link "libguilereadline-v-12") and
coexist peacefully with any newer version of guile that might need to
(dynamic-link "libguilereadline-v-13").

For scheme level modules, you can do the same thing -- you might have
(use-modules (g-wrap core-1)).  This is not as nice as some future
mechanism that might support levels of backward compatibility the way
that ld.so does, but it's probably less verbose that that solution
would be.  Compare (use-modules (g-wrap core-1)) to something like
(use-modules (g-wrap core #:interface 1)).

Of course if you're *sure* you don't want to support multiple
installed versions of g-wrap for a given installed version of guile,
then putting the scheme modules in a guile versioned subdir (one
that's only in the %load-path of the relevant guile), can fix the
scheme module problem, but putting the version/"soname" in the module
name is more flexible for the end user.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4