libtool release and version-info arguments need to be set correctly
-------------------------------------------------------------------
Key: AMQCPP-158
URL: https://issues.apache.org/activemq/browse/AMQCPP-158
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 2.1.2
Environment: Debian
Reporter: Daniel Pocock
Assignee: Nathan Mittler
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 libactivemq-cpp.la -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:
http://cwiki.apache.org/confluence/display/AMQCPP/ActiveMQ-CPP+product+version+number
http://cwiki.apache.org/confluence/display/AMQCPP/ActiveMQ-CPP%2C+libtool+and+packaging+notes
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.