The 0.5.0 -> 0.6.0 update breaks the ABI without changing soname

Create issue
Issue #197 resolved
Former user created an issue

Automatic migration. Original reporter: "HansdeGoede"

Short intro: I'm a Fedora developer and the maitainer of the Fedora cegui packages.

I've just finished updating our packages to 0.6.0, while doing this update I noticed (from comparing headers) that the ABI has changed, but the sonames have not, this is bad as it can lead to all kinda crashes. Its much better to change the soname in this case, this may still break applications because they can no longer start due to the linker not being able to find the old library, but atleast the reason for the breakage is clear then.

The attached patch changes to Makefile to pass -release instead of -version to libtool, causing libtool to embed the cegui version into the soname, so that the soname will change with each release, making clear that releases are not ABI compatible.

Note that this patch is meant to be applied on top of the patch to ensure linking against CEGUIBase for all CEGUI components, see: http://www.cegui.org.uk/mantis/view.php?id=196

Reproducibility: always

Comments (3)

  1. Former user Account Deleted

    Original reporter: HansdeGoede

    Oops, accidentally attached cegui-0.6.0-release-as-so-ver.patch again, please ignore.

    I've also attached cegui-0.6.0-userverso.patch which updates the dlopen handling code to handle the new soname's for CEGUI libs.

  2. Paul Turner

    Yeah, I missed the update of the libtool versioning when 0.6.0 was released - once this mistake was made it has kind of thrown out the situation for subsequent 0.6.x releases too (in 0.6.1 I only wanted to bump current & age, which would be technically correct as far as changes since 0.6.0, but obviously is still incorrect based on the 0.5.0 versions).

    I actually quite like the prospect of having the release version embedded in the object names, since it also resolves the issue of having multiple versions of the plug-in type modules - something else that I'd grown increasingly concerned about.

    Due to the large-ish nature of a naming scheme change like this, I'll make this change in trunk for what will eventually become 0.7.0.

  3. Log in to comment