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

Autotools configure different SONAME than the CMake build #479

Closed
coldtobi opened this issue Oct 21, 2020 · 4 comments · Fixed by #480
Closed

Autotools configure different SONAME than the CMake build #479

coldtobi opened this issue Oct 21, 2020 · 4 comments · Fixed by #480
Assignees

Comments

@coldtobi
Copy link

Hi,
I'm currently packaging the version 2.0.5 for Debian (https://tracker.debian.org/log4cplus) and I'm currently planning to use Cmake to create the build (to have the CMake module as well)

During that, I saw that the SONAME is different depending whether autotools or Cmake is used for build:

When using autotools:
Filenames are:

lrwxrwxrwx 1 tobi tobi       25 20. Okt 23:58 liblog4cplus-2.0.so.3 -> liblog4cplus-2.0.so.3.4.5
-rwxr-xr-x 1 tobi tobi 10871920 20. Okt 23:58 liblog4cplus-2.0.so.3.4.5
-rwxr-xr-x 1 tobi tobi      985 20. Okt 23:58 liblog4cplus.la
lrwxrwxrwx 1 tobi tobi       25 20. Okt 23:58 liblog4cplus.so -> liblog4cplus-2.0.so.3.4.5

SONAME with Autotools:

objdump -p liblog4cplus.so | grep SONAME
  SONAME               liblog4cplus-2.0.so.3

When using CMake:

Filenames are:

/build/log4cplus-2.0.5/debian/tmp/usr/lib/x86_64-linux-gnu# ls -la *so*
lrwxrwxrwx 1 pbuilder pbuilder       17 Oct 20 20:51 liblog4cplus.so -> liblog4cplus.so.0
lrwxrwxrwx 1 pbuilder pbuilder       21 Oct 20 20:51 liblog4cplus.so.0 -> liblog4cplus.so.2.0.5

SONAME with CMake:

objdump -p liblog4cplus.so | grep SONAME
  SONAME               liblog4cplus.so.0

My question is: What is the intended SO Name and file names?

Thanks for you help!

@wilx wilx self-assigned this Oct 21, 2020
@wilx
Copy link
Contributor

wilx commented Oct 21, 2020

There is no intended SO name. Autotools build uses what it offers and CMake build uses what CMake offers. I did not try to completely emulate what Autotools does with its semantic versioning within CMake. The Autotools build system also has configure script options to remove the SO version.

wilx added a commit to wilx/log4cplus that referenced this issue Oct 21, 2020
@wilx
Copy link
Contributor

wilx commented Oct 21, 2020

See wilx@aa1a04c. This could help. It propagates the main part of the SO version into CMake.

wilx added a commit to wilx/log4cplus that referenced this issue Oct 21, 2020
@wilx wilx linked a pull request Oct 21, 2020 that will close this issue
@coldtobi
Copy link
Author

Thanks for your answer, @wilx.

Please allow me one note on "There is no intended SO name":
SONAMEs are quite an important property of an shared library, e.g to declare ABI compatiblity; this is especially true in distribution context to avoid programm breaking because of incompatible changes; recompiling might not always bepossible…

Yes, Libtool is doing a great job on that one, unfortunately CMake seems to lack a bit here (generally remak, not only your project), so probably it would be best to manage SO Name in autotools and then simulating that in CMake.

(I'll need to come up with something anyway for the 2.05 Debian package; I'll see if I can provide something you could integrate)

If you make decision not to care about SONAMES:
(https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#static-libraries says thus implictly:) It is customary to say SONAME-Version "0" (zero) to denote an unmanaged/unstable AB.

Again thanks for the feeback and sorry to nag you again on the topic, but improper SONAME handling might indeed cause problems at your users…

Tobi

wilx added a commit that referenced this issue Nov 8, 2020
Deal better with SO version in CMake builds. Fixes #479.
@wilx
Copy link
Contributor

wilx commented Nov 9, 2020

With the changes I merged in, I get SO name like .so.3 with both Autotools and CMake. This is as close as we can reasonably get.

@wilx wilx closed this as completed Nov 9, 2020
wilx added a commit to wilx/log4cplus that referenced this issue Feb 24, 2021
wilx added a commit to wilx/log4cplus that referenced this issue Feb 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants