Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add libtool versioning to libgap shared library #3933

Merged
merged 1 commit into from
Apr 3, 2020

Conversation

fingolfin
Copy link
Member

We set up a libtool library version using the current:revision:age
format employed by libtool (see the libtool manual for details). We
currently do not use the revision value and use 0 instead. To avoid an
ever increasing number of versions, the kernel version is derived from
the libtool versioning info as follow:

kernel_major := current - age
kernel_minor := age

This provides the right semantics, provided we diligently follow the
rules for adjusting the values of current and age during releases,
as outlined in a comment in configure.ac.

Closes #3928

We could backport this to stabe-4.11, but that creates a somewhat iffy situation, as technically it would break the ABI going from 4.11.0 to 4.11.1; something we promised not to do. Yet one of the people who specifically asked whether we guarantee ABI stability in the 4.11 series, namely Bill Allombert from Debian, apparently is suggesting on the GAP mailing list that we do just that (however, I should qualify that this is just my understanding of what he said -- I may have misunderstood and don't want to misrepresent him). While that is all good and fine, I am not sure how other people packaging GAP would like this (e.g. @jamesjer working Fedora packages). Right now I think I'd prefer if we did not backport this, and just tell upstream packagers who want to know that GAP 4.12 will use the library version 8, so they can set any lower value for GAP 4.11, should they want to.

We set up a libtool library version using the `current:revision:age`
format employed by libtool (see the libtool manual for details). We
currently do not use the `revision` value and use 0 instead. To avoid an
ever increasing number of versions, the kernel version is derived from
the libtool versioning info as follow:

    kernel_major := current - age
    kernel_minor := age

This provides the right semantics, provided we diligently follow the
rules for adjusting the values of `current` and `age` during releases,
as outlined in a comment in `configure.ac`.
@fingolfin fingolfin added kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements topic: build system labels Mar 29, 2020
@coveralls
Copy link

Coverage Status

Coverage remained the same at 84.328% when pulling b2ccca8 on fingolfin:mh/shlib-versioning into abf18c2 on gap-system:master.

@jamesjer
Copy link
Contributor

I can cope with the situation either way. If you merge it, I will make the necessary package adjustments. If you don't ... well, then there is nothing for me to do until 4.12 is released. Thank you for letting me know about this so I can plan ahead.

@fingolfin fingolfin merged commit 45f1798 into gap-system:master Apr 3, 2020
@fingolfin fingolfin deleted the mh/shlib-versioning branch April 3, 2020 10:03
@ThomasBreuer ThomasBreuer self-assigned this Feb 17, 2021
@ThomasBreuer ThomasBreuer added the release notes: added PRs introducing changes that have since been mentioned in the release notes label Feb 17, 2021
@ThomasBreuer ThomasBreuer removed their assignment Feb 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements release notes: added PRs introducing changes that have since been mentioned in the release notes topic: build system
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants