[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    [jira] Resolved: (AMQCPP-158) libtool release and version-info
From:       "Timothy Bish (JIRA)" <jira () apache ! org>
Date:       2008-12-31 20:53:05
Message-ID: 79878514.1230756785814.JavaMail.jira () brutus
[Download RAW message or body]


     [ https://issues.apache.org/activemq/browse/AMQCPP-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Timothy Bish resolved AMQCPP-158.
---------------------------------

    Resolution: Fixed

> 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: Timothy Bish
> 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 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.


[prev in list] [next in list] [prev in thread] [next in thread]