activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Pocock (JIRA)" <>
Subject [jira] Commented: (AMQCPP-158) libtool release and version-info arguments need to be set correctly
Date Wed, 04 Jun 2008 23:47:00 GMT


Daniel Pocock commented on AMQCPP-158:

Could you include the existing changes in 2.2 anyway, but keep the case open for deeper investigation/comment?

I've posted it on debian-mentor to see if there are any ideas.

Incidently, your objdump output matches mine - I think this is correct now.  I tested on a
Debian box.

The generated library file is:

However, we could also generate a filename like this:

Notice that in the second variation, we are including the product version before the .so and
the ABI version after the .so

The most important feature, however, is the SONAME - and that now looks correct.

Notice (on my PC) that libc has version = 2.7, while ABI = 6:

/lib/ ->

daniel@srv1:~$ objdump -p /lib/ | grep SONAME

> libtool release and version-info arguments need to be set correctly
> -------------------------------------------------------------------
>                 Key: AMQCPP-158
>                 URL:
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>    Affects Versions: 2.1.2
>         Environment: Debian
>            Reporter: Daniel Pocock
>            Assignee: Nathan Mittler
>             Fix For: 2.3
> When make is invoked, libtool is asked to build the library with this command line:
> /bin/sh ../../libtool --tag=CXX   --mode=link g++ -ansi -pedantic -W -Wall -fPIC  -fstrict-aliasing
-Wstrict-aliasing=2 -Wno-long-long -g -O2 -version-info 2:1:2 -release 2.1.2  -o
-rpath /usr/lib activemq/core/libactivemq_cpp_la-ActiveMQConsumer.lo ...........
> Notice the `-release 2.1.2' argument to libtool?  Using a unique release number with
each build means that applications will only run with one specific build, and no others.
> Perhaps `-release 2' might be more appropriate?  This would mean that an application
that expects version 2.1.1 would still be willing to link with 2.2.0 (for example) at runtime.
 Alternatively, it may be better to omit the release argument, and just use version-info.
> The -version-info argument allows more fine-grained control - however, it is not meant
to be written as MAJOR:MINOR:REVISION.  The three values mean `version:revision:age', where:
> - version = ABI version, an integer that is increment whenever binary compatibility changes
> - revision = implementation (this number is incremented when there is a code change that
does not impact the binary interface)
> - age = how many previous versions are binary compatible, e.g if age = 2, then version,
(version - 1) and (version - 2) are all binary compatible - the age value specified for this
library (2) suggests that it is binary compatible to the original version (0).
> ABI version numbers are not the same as product version numbers.  If the product number
is 2.1.2, that does not mean the -version-info argument is 2:1:2.
> I have created some pages on the wiki to discuss version and packaging issues; these
issues need to be agreed upon by the community before a version scheme can be implemented
in the build system.
> I am willing to work on the details and contribute a patch for this once there has been
some consensus on which is the best versioning scheme to adopt and what level of binary compatibility
is expected.
> Wiki pages:

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message