activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <>
Subject Re: ActiveMQ-CPP libtool issues
Date Mon, 03 Dec 2007 19:09:29 GMT
I'm sure that there are a lot of things that we do wrong in the 
configure scripts, but so far I can't find anyone who really know what 
the right thing to do with the autotools is.  It would be nice if there 
was a "Best Practices" document for the autotools that we could refer to.

I personally have no time to really investigate this right now, probably 
won't till sometime next year. 

What I would do if you'd like to get something changed is:

1. Write a Jira issue documenting that there is a problem.
2. Investigate the problem and the correct solution
3. Describe in simple terms (not autoconf language) what the problem is 
and how to fix it.  Keep in mind that people how work on this project do 
so in their spare time and have extremely limited resources to read 
large bodies of documentation.
4. If applicable. Submit a patch that corrects the problem.

If the solution involves steps that the maintainer needs to follow when 
making a release then I'd recommend editing the Wiki for Creating 
This will ensure that when a release is made the maintainer has 
something to help them get it done correctly.


Daniel Pocock wrote:
> I've just been looking at the way libtool is used by ActiveMQ-CPP,
> in anticipation of creating some Debian packages.
> The parameters to -version-info are defined like this:
>  current = 2 = current interface version
>  revision = 1 = the revision of the library (binary compatibility is
> preserved across revisions)
>  age = 2 = the difference between the newest and oldest interface that
> this library implements
> The numbers above (2:1:2) are the values used when building ActiveMQ-CPP. 
> It appears
> that this is just the ActiveMQ-CPP version number - the libtool
> version-info has a
> completely different meaning.
> The second and third parameters may not be correct.  Why?
> - Is 2.0 and 2.1 binary compatible?  If no, then `current' must be
> incremented, just
>   changing revision is not sufficient.
> - Setting `age = 2' implies that 2.x, 1.x and 0.x are all binary
> compatible.  In other
>   words, we are asserting that no function prototypes or struct
> definitions have changed
>   between between the current version and version (current - age = 2 - 2 =
> 0 = 0.x).
> - For instance, if 1.x and 2.x are NOT binary compatible, age must be set
> to 0.
> It also appears that both -version-info and -release are used.  This may not
> be necessary.  Having a unique `release' for each release that breaks
> binary compatibility is a good idea.  However, does 2.x.2 break
> binary compatibility with 2.x.1?  If not, then release should just
> be 2.x instead of 2.x.2.
> It would be useful if you could have a look at the Debian Library
> Packaging Guide, particularly the section about choosing the
> package name and numbering conventions:
> Here is the libtool command issued on my system when using make:
> /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/libactivem
> q_cpp_la-ActiveMQConsumer.lo ...........

View raw message