Re: packaging the add-on libs...

[Rob Browning]

address@hidden writes:

> Yes, I know (that's why I know I was taking risks ;-). I felt uneasy
> then and still feel uneasy abut it (see below).

Well FWIW, I did some experimentation, and at least on debian systems,
during the process of re-building/uploading which would happen every
time we release a new major version of libguile, I determined that you
are likely to end up with cross-version-links.

In my example (imagine libbase is libguile):

  $ ldd .libs/some-app-2
        libuses-base-foo2.so.2 => not found
        libbase2.so.2 => not found
        libuses-base-bar.so.1 => not found
        libbase1.so.1 => not found
        libc.so.6 => /lib/libc.so.6 (0x40027000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Note that in the expirimental tree, some-app-2 was only linked via
libtool against libuses-base-bar and libuses-base-foo2, the two
libbase links were pulled in because uses-base-foo2 and uses-base-bar
were originally linked against two different versions of libbase.

I don't know if how this would work on other platforms, but what's
interesting is that at runtime, it appears that the loader resolves
any duplicate symbols in favor of the first library listed on the
libtool link line.  In this case, even though libuses-base-foo2 was
linked against libbase2, when it calls libbase_init, it prints the
message I put in libbase1's libbase_init.  There are no linkage
warnings.  libuses-base-bar was listed first on the libtool link line,
and if I reverse that so that libuses-base-foo2 comes first, then we
see the messages from libbase2.

In some sense, this could be seen as a good thing, and would hide most
problems, i.e. even though you have dual linkage, you always get the
symbols from just one version of the libs, but in reality I believe
it's a potential disaster since (for example) libuses-base-foo2 was
built using libbase2's headers, and libuses-base-bar was built using
libbase1's headers.  This means that one of them is going to be
operating on libbase data structures with the wrong set of macros.
Another potential problems comes if libbase2 adds new functions or
deletes old ones, then depending on whether libbase2 or libbase1 takes
precedence in the "dual link", you'll have some functions from one
version of libbase and some from another.

> Yes, kind of. Only that I'd substitute ``that aren't supposed to be
> directly linkable by'' for ``that have to go with guile to be linked
> by...''
>
> In other words, if you need guile in conjunction with libfoo, then
> libfoo has no business in /usr/lib or /usr/local/lib -- but rather
> in /usr/lib/guile/1.6/ (or something like that). IMHO, of course.

The main problem with this is that any apps or libs linked against
these "add-on" libs will have to do something special to access the
libs, i.e. -rpath, mangling LD_LIBRARY_PATH, etc.  and as we've
discussed, there are some definite issues with doing that portably,
and in a way that doesn't have the potential to interact badly with
other libs that might do the same thing, so we'd have to be cautious
when considering this approach.  For libs no-one's ever allowed to
link directly to, there's no problem.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD