[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Automake help with libGenome



On Sun, 24 Feb 2008, Aaron Darling wrote:

Is it a substantive problem that the library version appears twice in the .so name, or is it more of a cosmetic issue?

Well, it is in so far a substantive problem that if you are using the
Debian tool that is recommended to build packages from libraries
(d-shlibs) the resulting package name is obtained automatically from
the library name and thus you get finally a doubled version number
in the package name which is simply confusing.

The original reason behind specifying:

lib_LTLIBRARIES = libGenome-1.3.la

in Makefile.am instead of the expected:
lib_LTLIBRARIES = libGenome.la

was because of how automake names the resulting static libraries. If the latter incantation is used, the resulting static library is named simply "libGenome.la" and installs as libGenome.la without any versioning information.

Are you sure?  If you look into the libGenome-1.3.la which is generated
by your original source you get inside the file things like:

...
# The name that we can dlopen(3).
dlname='libGenome-1.3-1.3.so.1'

# Names of this library.
library_names='libGenome-1.3-1.3.so.1.0.3 libGenome-1.3-1.3.so.1 libGenome-1.3.so'
...

which is clearly not what you want, because the version 1.3 appears twice
which is exactly the reason why the Debian package will named very
unconventionally (at best).  The goal should not be to have the version
number in the library archive file name (libGenome.la) but in the dynamic
libraries (*.so) which also shows this doubled version number.

$ ls -l libGenome/.libs/*.so*
lrwxrwxrwx 1 tillea admin      26 2008-02-22 14:45 libGenome/.libs/libGenome-1.3-1.3.so.1 -> libGenome-1.3-1.3.so.1.0.3
-rwxr-xr-x 1 tillea admin 2799943 2008-02-22 14:45 libGenome/.libs/libGenome-1.3-1.3.so.1.0.3
lrwxrwxrwx 1 tillea admin      26 2008-02-22 14:45 libGenome/.libs/libGenome-1.3.so -> libGenome-1.3-1.3.so.1.0.3

Thus it becomes impossible to have parallel installs of versioned static libraries to match a parallel install of versioned shared libraries. I do not know whether this is simply an oversight in the design of automake/libtool or whether it was an intentional omission.

It is actually the goal of automake and it works for several projects
out of the box if you leave out the version in Makefile.am because you
give the correct versioning info in configure.ac (MAJOR, MINOR and MICRO).
There should be no other file that contains this version infor (at least
according to my understanding) which is sufficient to work with different
versions of a library (this is actually the idea of the d-shlibs tool
that builds versioned library packages to enable using different versions
of a library packaged).

In any case, I often require static libraries to build static binaries of Mauve since the target audience cannot be expected to build and install shared libs.

Hmm, several static libraries are handled a bit different.  In Debian
normally the -dev packages contain one version and conflict to other possible
-dev packages of the library which ensures that only one static library
can be installed at the same time.  If handling of different static
libraries is your concern I can not comment on this because I had not
to deal with this issue in automake.  In any case if I look into my /usr/lib
for static libraries with different names they all do not contain a dash
between libraryname and version and the packages (for instance libtcl8.0.a
and libtcl8.4.a) and so se verison becomes part of the whole name which
is something else than in your case.

I agree that repeated version numbers are not pretty, and if there's a more elegant solution to the static library versioning issue I would very much like to know about it!

Well, thanks for answering the issue from your point anyway.  I personally
see two solutions for the problem:

 1. I find a patch to automake stuff for the purpose of the Debian
    packaging which will remove the double version number.  (Well,
    in fact I did, but really strangely the '.so' extension is left
    out and I have to investigate why this happens at all.  It is a
    really strange libtool behaviour I never observed.)

 2. We find a way to add the version number to the static library
    without adding the version two times to the dynamic library.

Please tell me which solution you would prefer.  There is always the
option to ask on Debian devel mailing list where more automake experts
are hanging around.

Kind regards and thanks for your interest

        Andreas.

--
http://fam-tille.de


Reply to: