Re: library versioning: making upstream policy, need debian evaluation.
Andrew Suffield <asuffield@debian.org> writes:
> It does, and it's a perennial problem.
OK. Thanks. Seems like it might be nice (in many applications) to
have some way to at least detect when you end up with a process that's
linked against more than one version of a given lib (directly or
indirectly), though perhaps with many libs that's not necessarily an
error? In any case, with libguile it would likely be trouble.
> Within the SONAME model, which specifies a single monotonically
> incrementing version for every shared object, the only solution is
> to have upstream explicitly specify that libgwrap-glib.so.a is to be
> linked against libguile.so.x, and libgwrap-glib.so.b is to be linked
> against libguile.so.y, with specific versions. Ideally the build
> system would enforce this (autoconf macro, anyone?). This has to be
> consistant across all distributions if binaries are to be
> compatible.
Ahh, that would probably work, and I guess it's one of the only viable
solutions where binary distributions are concerned. (Aside: thinking
through a lot of this has definitely highlighted one of the strengths
of source-only distributions -- seems like they can be engineered to
generally avoid this problem...)
> Note that this only applies in the case where data types inherited
> from libguile form a part of the exported interface of libgwrap-glib.
OK, I can see that -- if the "add-on" lib exposes directly or
indirectly the data structures of a sub-library, then you may have
trouble.
> In the case of exported *functions*, they can be handled by versioned
> symbols in the linker. The problem is in the case of types, which
> cannot be versioned (this is a limitation of C in its current form,
> along with most other languages; there are workarounds, but that's
> another story).
Interesting, though I presume the versioned symbols fix only helps
under linux, the hurd, and some other small set of operating systems.
I guess it probably won't help with guile either since the guile API
or any add-on API will be passing around SCM objects nearly
exclusively. I suppose that in theory it might be possible to version
those objects explicitly, but that might be hard or impossible to do
effciently (since guile SCMs use a traditional integer/pointer tagged
encoding), and I explicit versioning would likely only allow you to
detect the problem, not avoid it.
FWIW the primary fixes we had discussed upstream for guile were as
follows, but none of them seem particularly palatable:
- put all guile libs (and guile add-on libs) in
/usr/lib/guile/VERSION/. However, since guile encourages direct
use of it's libs and add-on libs from C via -l, this would mean
having to deal with either -rpath, LD_LIBRARY_PATH, ld.so.conf, or
some other likely unacceptable system requirement.
- put the guile version in the name of the lib,
i.e. libguile1.6-gwrap-glib. This is deemed both ugly and
somewhat hard to defend as it would also suggest
libgwrap-guile1.6-glib1.2-crypt1...
- not allow direct linking. Handle all C symbol patchup at runtime
with some dlopen/dlsym approach. This would allow us to put the
libs anywhere, and to check API versions/compatibility to whatever
extent we like, but it's fairly onerous for the C-side programmer.
You'd have to somehow declare a bunch of function pointer
variables and then initialize them at module load time...
I can add to that your (good) suggestion that we require all the
add-on library maintainers to only allow a given soname of their
libraries to be built against a particular soname of libguile. Given
these, we still don't have an option that seems very "clean" or likely
not to easily go astray, but I guess with the linking model we have,
that may be be best we can do...
Thanks very much to both you and Junichi for the help.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Reply to: