[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Better support for transition to guile-1.6
From: |
Marius Vollmer |
Subject: |
Re: Better support for transition to guile-1.6 |
Date: |
20 Nov 2001 00:58:12 +0100 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 |
Rob Browning <address@hidden> writes:
> > I think we should work with the libtool guys to add this feature to
> > libltdl or libtool as a whole. Off hand, I think the libtool would
> > need to be changed so that multiple versions of a ".la" file can be
> > installed simultaneously.
>
> Already done yesterday :>
Ahh, need to read the libtool mails...
> > Before we have that feature, we can make sure that passing an absolute
> > file name to `load-extension' without an extension will work. We can
> > then tell people that need to distinguish between multiple versions of
> > a plugin that they can install each version into their own directory,
> > and pass the absolute filename (without ".so" suffix etc) to
> > `load-extension'.
>
> So people would need to name their libraries say libfoo4.so... and
> then you'd say (dynamic-link "libfoo4")?
Even better! I was thinking about putting them into specific
locations like $(libdir)/foo/4/libfoo.la and then using
(dynamic-link (string-append libdir "foo/4/libfoo"))
But just using $libdir/libfoo4.la is much simpler!
> If so, would libfoo4 be provided via a symlink, or what? We'll still
> need the plain old libfoo.so.4... around, otherwise direct C linking
> won't work right,
Yes, that would be the compromise until dynamic-link understands
versions. I don't think symlinks will work right since it might trick
the dynamic linker to load a library twice, under its two names.
> OK, so here's a first stab at a policy:
>
> 1) All of our libraries will be versioned, even "semi-internal"
> ones.
>
> 2) For the first release of a given library that needs to be
> dynamic-linked (i.e. our current releases), we'll just name them
> libfoo.X.so and you can access them from guile via (dynamic-link
> "libfoo").
>
> 3) For subsequent releases where the interface has changed in a
> backward compatible way, until we have a dynamic-link that
> supports an interface argument, the "interface number" must be
> added to the name of the shared library, so we would have
> libfooX.Y.so and would say from scheme (dynamic-link "libfooX").
> (I'm not sure whether or not X and Y would always be the same --
> I'd have to re-examine the libtool versioning algorithm).
>
> 4) Eventually we hope that dynamic-link will support an "interface
> number" argument and so we can drop the number in the library
> name and have instead (dynamic-link "libfoo" 4) or similar.
>
> Does that seem right?
Yes. How long do you think will we have to wait for versions in
dynamic-link?
> For debian, this means that guile's about to split into a much larger
> number of packages, I'll at least have to add:
>
> libguilereadlineX
> libqthreadsY
> libguilesrfi-srfi-4-0
> libguilesrfi-srfi-13-14-0
>
> so that we can support guile version transitions smoothly.
Is that a big problem or can it be mostly automated? (Is this where
Debian has its impressive package statistics from? ;-)
Just for understanding, why do we need these different packages?
Isn't it enough to put all libraries into one package?