Library soname was changed from 2 to 1 in 0.8.6

Issue #1123 resolved
Rémi Verschelde
created an issue

Hi there,

I'm updating my Mageia package for CEGUI from version 0.8.5 to 0.8.6, and according to the changelog it's a minor maintenance release in the stable branch.

Still, the library soname and major were changed (and set backwards), which is quite surprising:
- CEGUI 0.8.5 produced libCEGUIBase-0.so.{2,2.4.0} with soname libCEGUIBase-0.so.2
- CEGUI 0.8.6 produces libCEGUIBase-0.so.{1,1.5.1} with soname libCEGUIBase-0.so.1

I guess the intent was to use 2.5.1 and keep the major 2?

(Note: assigning against version 0.8.5 as the 0.8.6 target does not exist yet).

Comments (20)

  1. Lukas Meindl

    I went by the CMake description. The interface has not changed at all in 0.8.6, the changes were all in the source code of functions. @Martin Preisler and @Paul Turner can you assist on this please, I have no clue how this was intended and went straight by the instructions. It might be that the math for the SOVERSION is wrong here. If that is not the case then I do not know what is wrong.

  2. Paul Turner

    If there were no interface changes at all (meaning no modifications, no additions, no anything) and the only changes were in the implementation (meaning .cpp files only). Then you would increase REVISION and leave the other two values unchanged.

    This would give you: libCEGUIBase-0.so.{2,2.4.1} and SONAME libCEGUIBase-0.so.2

    Note that the instructions there for changing AGE and CURRENT refer specifically to the interface, so in this scenario, I believe neither should have been changed (and if you change one of them, you always change the other in some way).

    Hope this helps.

  3. Paul Turner

    0.8.6 should be withdrawn immediately and replaced with 0.8.7 that restores the corrected versioning as soon as possible. We can't have Linux distributions shipping this, it's about as huge a FUBAR as one could possibly create!

    The new version cannot have interface versions based on the incorrect 0.8.6, but would have to be taken from 0.8.5 and work from there - which likely means reverting to 0.8.5 values and then increasing REVISION by 2 (one for what should have been 0.8.6, and one for the new 0.8.7).

  4. Lukas Meindl

    Then I suggest we purge 0.8.6 from SF and release 0.8.7 asap. Sorry for the inconvenience and I will rephrase the SO version comments so that I won't misunderstand them again.

    It is actually a pretty obvious mistake in hindsight, also I guess Martin did not look over my changes or he would have most likely noticed it.

  5. Lukas Meindl

    With my last sentence, I meant that in hindsight the resulting SO is obviously wrong, but I had not calculated it and just followed instructions like Martin told me to do. Yes, I am one of those guys who do not think for themselves :D (by which I mean that I actually should have taken more responsibility here and calculated this to be sure!)

    Regarding your clear-up of the SO version increment rules: It seems to me that the rules in the CMAKE file comments are simply incorrect, no matter how I try to read them. @Paul Turner please check if these rephrased (based on what you said) and hopefully absolutely non-ambiguous and idiot-proof rules are correct now:

    Prior to issuing a release, modify the values as follows:

    • If there were no changes to the source, do not change any of the values

    • If there were changes to the source that are fully compatible with ABI and API, increase REVISION

    • If there were changes to the source that changed the ABI but are compatible with the API, increase AGE and REVISION

    • If there were changes that are incompatible with the API (thus, also with the ABI). increase CURRENT and set REVISION and AGE to 0

  6. Paul Turner

    The way it was listed before was a list of steps, not a set of options. The idea was to work down the list and apply the changes that applied from each of the steps.

    How you have it quoted above is either incorrect or still unclear (IMO), especially line 2, because if, say, you add a function, it's ABI and API compatible with what went before, but you would not apply line 2. Line 3 is also incorrect by my interpretation.

    I will clarify here that this version information has very little (effectively nothing) to do with API, it's about ABI (one could argue about things such as inline functions that get compiled into client code and not the library). But anyway, any mention of API in the 'rules' is a bit of a red flag to me.

    If you want it as a list of options, it should be something like below (IMO), but if this is still ambiguous, let's thrash it out some more, so that we can get a totally clear set of rules:

    • If there were no changes to the source, do not change any values.
    • If there were changes to the implementation, but no changes to the ABI at all (that is, nothing was added, removed, or changed that affects ABI), increase REVISION.
    • If there were changes that modified the ABI, but the ABI remains compatible with the previous release, increase CURRENT, increase AGE, and set REVISION to 0.
    • If there were ABI breaking changes, increase CURRENT, set AGE to 0 and set REVISION to 0.
  7. Lukas Meindl

    Based on what you wrote now it is obvious to me I would have to increase the revision and the revision only.

    Now quoting from what it originally said:

    If the interface had binary compabilbe additions only (so no ABI breaking changes) increase AGE, else set AGE to 0.

    it had binary compatible additions only (nothing was added to the source that is not binary compatible) so I increased the age. Also this says "otherwise..." which implies you always either increase the age or st it to 0. So your point #2 would mean either of the two: increase or set to 0, would have to take place. That's why I got really confused by the original text.

  8. Paul Turner

    Yes, I can see that it was confusing, especially as it said nothing about how those instructions were to be used.

    In the case there were ABI compatible additions, the process should have been this:

    If there were any changes in the source, increase REVISION

    There were changes to the source, so we should increase REVISION.

    If the interface changed at all, increase CURRENT and set REVISION to 0

    There were additions, so the interface changed, which means we would now increase CURRENT and set REVISION back to 0.

    If the interface had binary compabilbe additions only (so no ABI breaking changes) increase AGE, else set AGE to 0.

    The changes were binary compatible, so now we would increase AGE.

    Clearly the way the rules were supposed to be used was not explained at all, which lead to the confusion.

    Based on what you wrote now it is obvious to me I would have to increase the revision and the revision only.

    Given that you said the following:

    it had binary compatible additions only (nothing was added to the source that is not binary compatible)

    The correct thing would be to increase CURRENT and AGE, and set REVISION to 0 (point 3 of the new proposed text). Only if there were compatible changes, but no additions of any kind, would we only increase REVISION.

    My earlier comment about increasing REVISION by 2 assumed there were no additions to the ABI, since you say there were, the correct thing is to increase CURRENT and AGE, and set REVISION to 0.

  9. Lukas Meindl

    There were no additions to the ABI at all, which TO ME meant that the "additions" (to the cpp files) were ABI compatible (because they did not modify the ABI in any way they must be compatible, but that's not how it was meant to be read). And that would make me, who just follows text, do the last thing you just said instead of the paragraph before.

    I understand how you mean this now and correct would have been : Only increase Revision.

  10. Paul Turner

    Given the discussion here, I believe this to be correct.

    Side note: Sent a reply last night via email, but it did not show here. Anyone know why that is, and how to make it work via email?

  11. Log in to comment