Bundling G-Wrap

Rob Browning rlb at defaultvalue.org
Sun Jul 11 13:31:15 EDT 2004

linas at linas.org (Linas Vepstas) writes:

> On Fri, Jul 09, 2004 at 05:58:43PM +0200, Andreas Rottmann was heard to remark:
>> I'm willing to change this.
> Thanks, that would be really great!  

Yes.  Things should get a lot better on that front now (many thanks to

> Again, this is the expression of the major-vs-minor version number
> tirade: Its OK if libfoo-1.4-dev clobbers the files in
> libfoo-1.2-dev because its expected that libfoo-1.4-dev is backwards
> compat.  However, libfoo2-dev *must* be installable in parallel with
> libfoo-1.4-dev so that both are usable.  Again, the version
> numbering problem is a technical problem, not a mater of taste or
> opinion.

This can be a tough issue given the available tools (and one that we
discussed quite a bit on debian-devel and guile-devel a while back
(a year or two?)).

Right now, libtool's dlopen, which is what guile uses via
libguile-ltdl (which supports dynamic-link) doesn't support any kind
of versioning.  So you can only try to link "libfoo", and if you have
a libfoo.so.5 and a libfoo.so.10, there's no way to ask for a specific
one, you just get the one libtool picks.  This makes it difficult to
have two installed versions of anything loaded via dynamic-link.

What probably needs to happen, and what we've discussed, is to add a
dlopen_version(name, version_info) which uses the same algorithm that
ldso uses.  Then we would be able to provide a dynamic-link that lets
you ask for soname X or better (dynamic-link "libfoo" N), which is
what implicitly happens with ldso style -l linking.  It'd be really
nice if libtool would be willing to add this, but we can always get
started and then offer a patch via our libguile-ltdl.

In any case, until/unless the above happens, the easiest thing to do
that doesn't involve putting libraries in non FHS locations and
requring mucking about with LD_LIBRARY_PATH (even for "standard
installations") is probably to just include the version number (or
soname) in the library name, i.e. you have libgw-guile-standard-20.so
and hence (dynamic-link "libgw-guile-standard-20").

I believe here were a number of other options discussed, though
without a suitably flexible dlopen, it can be difficult to come up
with solutions that won't break expectations, tools, or violate FHS or
packaging requirements.

There might have been consideration of one other option that hadn't
been shot down yet, but if I recall correctly, it hadn't been
determined if it would be "OK" either.  I think the idea was to put
the libs in /usr/lib without versions in the names, and then also
provide a symlink for dlopen/dynamic-link:

  /usr/lib/libfoo-N.so -> libgw-guile-foo.so.N

Given that, you can still use (dynamic-link "libgw-guile-foo-N"), but
nothing else has to deal with the versioned name.  Of course if you
want to support multiple installed dev versions in general, then you
probably want the version in the name anyway, i.e. -lfoo-5 and

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

More information about the gnucash-devel mailing list