bugCERTI - Bugs: bug #24904, Wrong shared library versioning


bug #24904: Wrong shared library versioning

Submitter:  Petr Gotthard <gotthardp>
Submitted:  Sat 22 Nov 2008 07:34:38 PM UTC
Category:  CERTI Severity:  * 4 - Important
Item Group:  Compilation error Status:  In Progress
Privacy:  Public Assigned to:  gotthardp
Open/Closed:  Open Release:  * CVS
Reproducibility:  Every Time Fixed Release:  * Unknown
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Sun 04 Apr 2010 04:51:04 PM UTC, comment #8: 

Patch OK for me.
Go ahead apply it.

Concerning shared library handling with CMake
look at the USE_FULL_RPATH OPTION in CERTI main CMakeLists.txt.

Have a look at
as far as I understand this concerns only unix but I may be wrong.

May be the:
CMakeVerifyManifest.cmake macro (since CMake 2.8.0)
may be interesting to check too.

And last but not least the following blog entry may
be valuable to read too:

Eric NOULARD <erk>
Group administrator
Sun 04 Apr 2010 01:08:04 PM UTC, comment #7: 

as a first step I propose this patch;

then I will check the windows manifests generated and may propose another update

(file #20113)

Petr Gotthard <gotthardp>
Group Member
Sun 21 Mar 2010 11:26:51 AM UTC, comment #6: 

OK understood, I do agree for the severity bump.
Waiting for the patch proposal.

Eric NOULARD <erk>
Group administrator
Sun 21 Mar 2010 10:28:29 AM UTC, comment #5: 

Increasing severity: implementing versioning and manifests under Windows is an important precondition for successful installers.

Each CERTI application/library should have an embedded manifest listing what library versions are compatible with this executable.

I'm going to propose a patch.

Petr Gotthard <gotthardp>
Group Member
Tue 25 Nov 2008 06:06:10 PM UTC, comment #4: 

I'm ok with the latest principle.
i.e. with your summary.

It's a good beginning if the SO version
seems to go too fast we will design a new evolution scheme
but your proposal seems good to me with our current
development process.

Go ahead with this.
After that I may begin the necessary build system work
in order to begin to build 1516 versions of the libs.

Eric NOULARD <erk>
Group administrator
Mon 24 Nov 2008 02:04:47 PM UTC, comment #3: 

Of course, this would require the CERTI major/minor number to change if and only if the "internal API" is changed (new message/function is added).
Otherwise, only the patch number 3.2.x should change.

Petr Gotthard <gotthardp>
Group Member
Mon 24 Nov 2008 12:56:07 PM UTC, comment #2: 

This is also related to the bug #24854.

Incrementing SO version with CERTI version (the 1-1 relation) is an easy way to avoid library compatibility problems: everything that was shipped together linkes together and nothing else.
Other relations may be more user-convenient, but requires CERTI developers to track and test the API compatibility.

1) The libRTI-NG and libFedTime
Here the 1-1 relation is obviously wrong, you're right. The API does not change. We may even leave 1.0.0 here, because the libRTI versioning is implemented through changing the name (librti13, librti1516).

2) The libHLA
It is a standalone library, so may have own numbering. On the other hand, tracking down the API changes in a library like libHLA may be very problematic.
I'm not sure here, having 1-1 is easier for CERTI development and not so inconvenient for the developpers. It just requires a single rebuild.

3) The libCERTI
I belive that libCERTI of version X.Y should be tightly linked to RTIA/RTIG of this version, so libCERTI should have the same SO version as CERTI. It's an internal library. Rebuild is not required when libCERTI version changes.

libHLA, libFedTime : fixed 1.0.0 (current solution)
libCERTI: CERTI version (solution from my previous patch)
libHLA: CERTI version (because it's easier for me, many development libraries does this), but fixed 1.0.0 is also fine

What do you think?

Petr Gotthard <gotthardp>
Group Member
Mon 24 Nov 2008 12:25:27 PM UTC, comment #1: 

There is no good reason for not using it.

However we should not just bind the SOVERSION to
the CERTI version because many CERTI version will
  - at API level for linking
  - at ABI level for the on-the-wire protocol.

We should only make the lib version increment.
   lib.so.X.Y is compatible with lib.so.X.Z (for any Z)
   i.e. you may upgrade the lib without recompiling your app.
   lib.so.X.Y is INcompatible with lib.so.W.Z for any
     X != W.

More information on shared libs and DSO:

I think your are right we should handle lib versioning
but lib versionning should not be a 1-1 mapping
from CERTI version.

Ideally each lib (RTI[-NG], FedTime, CERTI, HLA)
should have it's own version, which will be loosely
linked with [global] CERTI version.

Eric NOULARD <erk>
Group administrator
Sat 22 Nov 2008 07:34:38 PM UTC, original submission:  

Is there any reason not to use the library versioning?

Currently the version is always 1.0.0, what may lead to problems when different libraries are used during compile- and run- time.

Patch attached.

Petr Gotthard <gotthardp>
Group Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #20113:  versioning.patch added by gotthardp (776B - text/x-patch - Second proposal.)
file #16901:  versioning.patch added by gotthardp (3KiB - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by erk (Posted a comment)
  • -email is unavailable- added by gotthardp (Submitted the item)

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-04-04 gotthardp Attached File- Added versioning.patch, #20113
    2010-03-21 gotthardp Severity2 - Minor 4 - Important
        StatusNone In Progress
    2008-11-24 erk Fixed ReleaseNextRelease Unknown
    2008-11-22 gotthardp Attached File- Added versioning.patch, #16901

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code