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.

Sign up for GitHub

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

Jump to bottom

Different soname versions when built using autotools and cmake #1857

Open
balasankarc opened this issue Apr 7, 2023 · 7 comments · May be fixed by #1976
Open

Different soname versions when built using autotools and cmake #1857

balasankarc opened this issue Apr 7, 2023 · 7 comments · May be fixed by #1976

Comments

@balasankarc
Copy link

Following https://github.com/libarchive/libarchive/wiki/BuildInstructions#building-libarchive-from-the-github-source-code, when v3.6.2 is built from distribution tarball (https://www.libarchive.org/downloads/libarchive-3.6.2.tar.gz) and by checking out the git tag (https://github.com/libarchive/libarchive/releases/tag/v3.6.2), the generated files seems different. These are the results I got (target directory names should be self-explanatory)

root@c468ac8cddcc:~# tree /tmp/libarchive-with-autotools-from-tarball/lib/
/tmp/libarchive-with-autotools-from-tarball/lib/
|-- libarchive.a
|-- libarchive.la
|-- libarchive.so -> libarchive.so.13.6.2
|-- libarchive.so.13 -> libarchive.so.13.6.2
|-- libarchive.so.13.6.2
`-- pkgconfig
    `-- libarchive.pc

1 directory, 6 files
root@c468ac8cddcc:~# tree /tmp/libarchive-with-cmake-from-git-tag/lib/
/tmp/libarchive-with-cmake-from-git-tag/lib/
|-- libarchive.a
|-- libarchive.so -> libarchive.so.19
|-- libarchive.so.19
`-- pkgconfig
    `-- libarchive.pc

1 directory, 4 files

By print-debugging, I confirmed that both the methods compute interface version to be 19, but for some reason the build from tarball creates .so.13.6.2 file while the one from git tag creates .so.19 file. Any idea why it is so?
@balasankarc
Copy link
Author

balasankarc commented Apr 7, 2023 •
edited

On more testing, building using autotool will make.so.13.6.2 files from both distribution tarball and git tag. Building using cmake will make .so.19 files from both distribution tarball and git tag.

@balasankarc balasankarc changed the title Different soname versions when built from distribution tarball and git tag Different soname versions when built using autotools and cmake Apr 7, 2023
@kientzle
Copy link
Contributor

kientzle commented Apr 7, 2023

To be honest, I could never figure out how autotools computes soversions. (I believe that in the past, different autotools distributions computed it differently.)

@dmacks
Copy link

dmacks commented Apr 19, 2023

In the autotools toolchain, soversion is via libtool's -version-info flag (see full docs). Its parameter-set is "c:r:a", and the soname becomes "c-a". In the libarchive-3.6.2 release, it's -version-info 19:2:6: 19-6=13, giving libarchive.so.13. The more-specifically versioned files are an artifact of libtool, and indeed do change (or are omitted altogether) on various platforms and libtool versions, but are also irrelevant. The soname filename is the one accessed both at link-time and run-time.

@jaimergp jaimergp mentioned this issue Aug 29, 2023
Open
1 task
@jaimergp
Copy link

I am trying to make two build platforms generate the same SONAME, but one of the uses CMake and the other one autotools, so we are hitting this.

Given libarchive's excellent ABI compatibility (see abi-laboratory report), it looks like autotools's SOVERSION (13) is correct: all releases after 3.1 are intended backwards compatible.

Given a $major.$minor.$patch version string, the $current:$revision:$age libtool string libarchive uses is given in this block:

libarchive/configure.ac

Lines 34 to 49 in 67a20ce

# Libtool's "interface version" can be computed from the libarchive version.
# Libtool interface version bumps on any API change, so increments
# whenever libarchive minor version does.
ARCHIVE_MINOR=$(( (LIBARCHIVE_VERSION_N() / 1000) % 1000 ))
# Libarchive 2.7 == libtool interface 9 = 2 + 7
# Libarchive 2.8 == libtool interface 10 = 2 + 8
# Libarchive 2.9 == libtool interface 11 = 2 + 8
# Libarchive 3.0 == libtool interface 12
# Libarchive 3.1 == libtool interface 13
ARCHIVE_INTERFACE=`echo $((13 + ${ARCHIVE_MINOR}))`
# Libarchive revision is bumped on any source change === libtool revision
ARCHIVE_REVISION=$(( LIBARCHIVE_VERSION_N() % 1000 ))
# Libarchive minor is bumped on any interface addition === libtool age
ARCHIVE_LIBTOOL_VERSION=$ARCHIVE_INTERFACE:$ARCHIVE_REVISION:$ARCHIVE_MINOR

In other words:

  • current: 13 + $minor
  • revision: $patch
  • age: $minor

As per @dmacks above, the SONAME is $current - $age, so 13 + $minor - $minor = 13.

However, in CMake we have that SOVERSION is set to:

libarchive/CMakeLists.txt

Lines 72 to 82 in 67a20ce

# INTERFACE_VERSION increments with every release
# libarchive 2.7 == interface version 9 = 2 + 7
# libarchive 2.8 == interface version 10 = 2 + 8
# libarchive 2.9 == interface version 11 = 2 + 9
# libarchive 3.0 == interface version 12
# libarchive 3.1 == interface version 13
math(EXPR INTERFACE_VERSION "13 + ${_minor}")
# Set SOVERSION == Interface version
# ?? Should there be more here ??
SET(SOVERSION "${INTERFACE_VERSION}")

In other words, 13 + $minor, but it should be just 13. Hence the difference.

So, in practice, autotools is hardcoding the SONAME version to 13, and CMake is doing 13 + $minor... which one is intended by the maintainers? It feels like autotools way is preferred, given how in the past the SONAME has been bumped manually (see bdf2c17 or ecd860e). I have a PR ready to implement this change if this assessment is correct.

This was referenced Sep 18, 2023
Open
Open
@tobiasdiez tobiasdiez mentioned this issue Oct 2, 2023
Open
5 tasks
@josch josch mentioned this issue Oct 14, 2023
Open
@tobiasdiez tobiasdiez mentioned this issue Oct 16, 2023
Merged
5 tasks
vbraun pushed a commit to vbraun/sage that referenced this issue Oct 19, 2023
sagemathgh-36468: Fix mamba install in conda ci workflow
acb1953 
    
<!-- ^^^^^
Please provide a concise, informative and self-explanatory title.
Don't put issue numbers in there, do this in the PR body below.
For example, instead of "Fixes sagemath#1234" use "Introduce new method to
calculate 1+1"
-->
<!-- Describe your changes here in detail -->

<!-- Why is this change required? What problem does it solve? -->
<!-- If this PR resolves an open issue, please link to it here. For
example "Fixes sagemath#12345". -->
<!-- If your change requires a documentation PR, please link it
appropriately. -->

Mamba currently has problems with dependencies installed from other
channels (libarchive/libarchive#1857,
conda-incubator/setup-miniconda#292,
conda-forge/libarchive-feedstock#69), see eg h
ttps://github.com/sagemath/sage/actions/runs/6525067702/job/17717363515.

As workaround we use miniforge now (which comes with a preinstalled
mamba from conda-forge)

### 📝 Checklist

<!-- Put an `x` in all the boxes that apply. -->
<!-- If your change requires a documentation PR, please link it
appropriately -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
<!-- Feel free to remove irrelevant items. -->

- [ ] The title is concise, informative, and self-explanatory.
- [ ] The description explains in detail what this PR is about.
- [ ] I have linked a relevant issue or discussion.
- [ ] I have created tests covering the changes.
- [ ] I have updated the documentation accordingly.

### ⌛ Dependencies

<!-- List all open PRs that this PR logically depends on
- sagemath#12345: short description why this is a dependency
- sagemath#34567: ...
-->

<!-- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
    
URL: sagemath#36468
Reported by: Tobias Diez
Reviewer(s): Isuru Fernando, Matthias Köppe
@smcv
Copy link

smcv commented Oct 19, 2023

cc @ppentchev since this will impact Debian packaging. There is some discussion on #1976 about whether the preferred thing to do is to increase the SONAME used with Autotools from libarchive.so.13 to match CMake's libarchive.so.19, or to reduce the SONAME used with CMake from libarchive.so.19 to match Autotools' libarchive.so.13.

If the SONAME used with Autotools is bumped from libarchive.so.13 to match CMake's libarchive.so.19, it might be tempting for downstream packagers who are using Autotools to patch the build system to revert to .so.13 to avoid rebuilds, but I would advise against that: a similar thing was done in the past for Debian's libcurl, and that divergence from the upstream ABI continues to cause weirdness more than a decade later.

@ppentchev
Copy link
Contributor

Thanks, @smcv, for the ping. Yeah, if the SONAME is bumped to .19, the Debian packaging will follow that, even if it means a trip through the Debian archive's NEW queue; the other way is indeed not worth the future headaches.

@evelikov
Copy link
Contributor

Great news, thanks gents. Also hello fellow countryman o/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix SOVERSION computation logic in CMake to match libtool's jaimergp/libarchive
7 participants
@ppentchev @evelikov @dmacks @kientzle @smcv @balasankarc @jaimergp