questions about general shlibs evilness

[Ari Heitner <aheitner@zedboy.net>]

Hi,

I'm packaging SashXB (sashxb.org, preliminary debs available). I'm trying to
fix the remaining evilnesses ("hey kids, can you find *all three* questions
in this rediculously long email?").

I get a lot of errors from dpkg-shlibdeps during build, which look like
this:
  dpkg-shlibdeps: warning: format of libgkgfx.so not recognized
  dpkg-shlibdeps: warning: format of libgtkembedmoz.so not recognized
They come up on libraries within the sashxb pkg, and on libs in
mozilla-browser. I looked thru dpkg-shlibdeps but my perl isn't nearly good
enough to understand the test it's doing (line 113):
    while (<P>) {
        chomp;
        if (m,^\s*NEEDED\s+,) {
            if (m,^\s*NEEDED\s+((\S+)\.so\.(\S+))$,) {
                [...]  
            } elsif (m,^\s*NEEDED\s+((\S+)-(\S+)\.so)$,) {
                [...]
            } else {
                m,^\s*NEEDED\s+(\S+)$,;
                &warn("format of $1 not recognized");
            }
        }
    }
greek to me :-)

On a hunch that the problem was that mozilla-browser does not provide a  
shlibs file (which, according to Policy 9.6 should cause a different error:
"warning: unable to dinfd dependency informatin for shared library <foo>"),
I wrote a shlibs.local file. Unfortunately, mozilla-browser does not version
its shared libs (even tho they're in /usr/lib, yes, already filed a bug on
it). Since I don't know any syntax for a shlibs file w/o version numbers, I
just put lines like:
  libgkgfx        0 mozilla-browser (>= 1.0.0)
but I suspect it's not doing any good. So that's question #1: what to do   
about these misbehaving mozilla libraries?

If that's actually the problem with mozilla's shared libs, then it's the
problem with dpkg-shlibdeps on my own libs, which are also unversioned. But
that I should have the power to fix, I just need to figure out how to do
that to make the debian tools happy. Here's the thing: we're not using
libtool -- it's too broken for the fairly complex things we have to do to
get all our bits to link (we used to. we suffered greatly. we stopped). So
we build .so's by having our automake bin_PROGRAMS = libsash<foo>.so and
just passing in a -shared in libsash<foo>_so_LDFLAGS.

But this makes it rather hard to rename our libraries correctly with
${VERSION} in Makefile.am. Which is easy enough to get around anyhow: just
build them the same way we have been, and add a little magic in the
install-exec-local rule in each Makefile.am to rename the libraries and add
the symlinks (can't rely on ldconfig to do that, our libraries are out of
the main path, and don't really need to be in the main path). Which is dandy
... but will it help the debian buildtools? I suspect not. So that's
question #2: what's a sane way to generate versioned libraries when not
using libtool? There must be some friendly example, my understanding is that
libtool isn't widely-loved around debian parts...

Finally, I'm attempting to generate my own .shlibs file with a line in
debian/rules:
  dh_makeshlibs -v --noscripts
but it's not doing generating one. The output (because -v is on) looks like:
  dh_makeshlibs -v --noscripts
        rm -f debian/sashxb/DEBIAN/shlibs
        install -d debian/sashxb/DEBIAN  
        rm -f debian/sashxb-dev/DEBIAN/shlibs
but I'm not sure what it would look like if it was generating one ... so
that's question #3: is there something else wrong than my libs having   
malformed names (b/c of no version number)?

...
   
whew.

please cc: me on replies.

Ran this by Matt Danish and he said "That's why I use Common Lisp: no shared
library hell" :-)



Cheers,

Ari Heitner