After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 658905 - LT_CURRENT is changed throughout the build
LT_CURRENT is changed throughout the build
Status: RESOLVED FIXED
Product: folks
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: Unset
Assigned To: folks-maint
folks-maint
Depends on:
Blocks:
 
 
Reported: 2011-09-13 11:15 UTC by Rodrigo Moya
Modified: 2011-09-14 11:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Rodrigo Moya 2011-09-13 11:15:55 UTC
LT_CURRENT is defined to be 26, but the build produces:

libfolks.so.25.1.1

but correctly installs backends under:

$prefix/lib/folks/26/backends

If I change LT_CURRENT in configure.ac to 27, it produces libfolks.so.26.1.1
Comment 1 Raul Gutierrez Segales 2011-09-13 12:34:46 UTC
(In reply to comment #0)
> LT_CURRENT is defined to be 26, but the build produces:
> 
> libfolks.so.25.1.1
> 
> but correctly installs backends under:
> 
> $prefix/lib/folks/26/backends
> 
> If I change LT_CURRENT in configure.ac to 27, it produces libfolks.so.26.1.1

First of all, I am not really sure how libtool is suppose to define the library's filename. But I think this is actually right. Doesn't it mean that the current library (libfolks.so.25.1.1) supports interfaces 25 and 26, up to revision 1?

If I set LT_AGE to 0 (and LT_REVISION to 0, but that doesn't matter) I would get:

libfolks.so.26.0.0 

meaning it only supports interfaces >= 26 (and the reason would be that LT_AGE was set to 0, meaning public API was dropped, causing us to be incompatible with the previous interfaces).
Comment 2 Philip Withnall 2011-09-13 17:12:12 UTC
As Raúl says, I think our behaviour is correct as per the libtool versioning documentation: http://www.gnu.org/s/libtool/manual/html_node/Libtool-versioning.html.

Please re-open the bug if you think it's not.
Comment 3 Rodrigo Moya 2011-09-14 11:19:06 UTC
hmm, this is the 1st time I see this, but I'm not saying it's incorrect, of course. But, if this is the case, then I guess you should set it to 26.0.0 when increasing LT_CURRENT, right?
Comment 4 Raul Gutierrez Segales 2011-09-14 11:23:04 UTC
(In reply to comment #3)
> hmm, this is the 1st time I see this, but I'm not saying it's incorrect, of
> course. But, if this is the case, then I guess you should set it to 26.0.0 when
> increasing LT_CURRENT, right?

Why? We follow these rules (again, I kinda do this blindly as I am not versed in libtool stuff, but as far as I can follow it makes sense):

# If library source has changed since last release, increment revision
# If interfaces have been added, removed or changed since last release,
#  increment current and set revision to 0
# If interfaces have been added since last release, increment age
# If interfaces have been removed since last release, set age to 0
m4_define([folks_lt_current], [26])
m4_define([folks_lt_revision], [1])
m4_define([folks_lt_age], [1])

So as long as we are not removing interfaces, age shouldn't be 0. And if we just changed the source but haven't added/removed/changed a public interface, revision just keeps going up.