[libcmml-dev] libcmml.0 vs libcmml.so.0

[Jamie Wilkinson]

So the Debian shared library finding scripts make a few assumptions
about shared libraries, and that's that the string '.so' appears
somewhere in the filename.  This is probably dumb, but there's not
really much else to go on (except maybe finding *every* file, using file
to see if it's an ELF, and then using objdump to see if the thing has a
SONAME in it, but that's another story).

So, when you go to check your binaries (say, cmml-validate) against the
list of known shlibs and so you can work out which packages you need to
depend on, you go Oh!  Here's a libcmml.0!  What the fuck is that!

A quick patch later, you find yourself going libcmml.0!  That's cool!
Where the fuck does that come from?  and then we run into the problem
described in the first paragraph.

So all this may sound dumb, but the easiest way around it right now is
to fix libcmml's build process to work out why the hell there's no '.so'
in the filename.

I can't see any difference between libannodex's and libcmml's
configure.ac that would make a difference to the way libtool runs, but
it looks like ltmain.sh in the libcmml source is about 2 years older
than libannodex's.

I reran libtoolize --automake --copy on the tree and rebuilt.

Success!  Now there's a libcmml.so.0 in src/.libs and everything's fine.
Phew, that was a long winded way of getting to my point.

Looks like version 1.4.2 of libtool isn't cool.  Well, every version of
libtool lacks cool, but 1.5.0a which is on my Debian unstable machine
and in libannodex does the right thing in this case.

-- 
jaq at spacepants.org                           http://spacepants.org/jaq.gpg