Set both VERSION and SOVERSION for target snappy #45
Conversation
Set proper values for properties `VERSION` and `SOVERSION` of target `snappy`, so that CMake produces the link `libsnappy.so.1` to the shared library `libsnappy.so.1.1.5` that is built. This link was available in 1.1.4 (with autotools) and it is still necessary for the run time linker to work. Its absence leads to run time errors like "error while loading shared libraries: libsnappy.so.1: cannot open shared object file: No such file or directory".
|
@pwnall @alkis this same issue was reported to Homebrew: Homebrew/homebrew-core#15274 For 1.1.5 we switched from Autotools to CMake (because there was no release tarball and because the Autotools build is currently broken due to README not being found, as Makefile.am only produces README.tmp, not README). But apparently the switch to CMake has broken the hadoop build due to the missing libsnappy.1.dylib file. |
|
It seems this change will require all the reverse dependencies to be bumped again, unfortunately. I'm not entirely sure why, because that does not seem to be the case if I use an Autotools build. |
|
@gdsotirov is it possible Autotools is also not setting VERSION now? |
|
I made a mess when I bumped the autotools SOVERSION, in 513df5f. I missed the memo about how libtool versions translate to soversions at https://github.com/google/snappy/blob/1.1.5/configure.ac#L6. Given that the autotools SOVERSION for snappy 1.1.4 is 1.3.1, I propose re-releasing 1.1.5 as 1.4.0, with SOVERSION set to 1.4.0 for both CMake and autotools. Per the notice in the 1.1.5 release, 1.4.0 would be the last release with autotools support. Afterwards, the insanity can end. (Quick) input on this proposal is welcome. I plan to make it happen fairly soon. |
|
@ilovezfs If you prefer to revert to autotools until we figure out the CMake situation, I think you can get the tarball you'd need at https://github.com/google/snappy/archive/1.1.5.tar.gz |
@ilovezfs Yes, for which I initially made PR #42. However, in 1.1.5 with Autotools I get
@ilovezfs I'm really not sure I understand you on this.
@ilovezfs With Autotools in 1.1.5 I'm getting
@pwnall This would work as well as long as the |
|
I have wrote to @pwnall by email, but with CMake in 1.1.5 there is also the problem that LIBDIR isn't configurable (e.g. I cannot set |
If I adopt this PR, then the dependents (AKA reverse dependencies) break with this error: |
|
@ilovezfs I understand you now, but I do not use Apple, so I'm not able to check and find remedy for this myself. I however guess the difference is coming from SOVERSION property being set to just ${PROJECT_VERSION_MAJOR}. However, if I set it the same as VERSION or leave it unset (in which case it should be same as VERSION as CMake's documentation states) the result is that symbolic link |
|
@gdsotirov to be clear, I don't mind if we need to rebuild the rev-deps, if that's the right thing to do. I'm just noting that this change has consequences beyond the creation of the symlink. |
|
@ilovezfs And I got your point, but I'm really not sure how to get CMake to create the necessary for Linux's run-time linker |
|
@gdsotirov yeah I think your solution is likely correct. |
|
I looked into version numbers some more. On OSX, I used Linux looks easy -- the only number that matters (as far as I can tell) is the major SOVERSION. However, in OSX, the situation is a bit more complicated. 1.1.4 autotools: /usr/local/lib/libsnappy.1.dylib (compatibility version 5.0.0, current version 5.1.0) 1.4.0 would look like this: autotools (libtool version [5:0:4]): /usr/local/lib/libsnappy.1.dylib (compatibility version 6.0.0, current version 6.0.0) After looking at the numbers (discussed below), I'm also considering releasing a 1.1.6, which would look like this: 1.1.6 autotools (libtool version [2:6:1]): /usr/local/lib/libsnappy.1.dylib (compatibility version 3.0.0, current version 3.6.0) What I don't like about both alternatives: according to the dylib compatibility / current versions, upgrading from an autotools build to a cmake build looks like an incompatible downgrade. The only way to avoid this seems to be re-releasing 1.1.5 as 6.0.0, which seems excessive. 1.4.0's advantage over 1.1.6 is that the autotools version numbers aren't disrupted, so users can stay on the autotools train for one more version without any problem. However, the version number 1.1.6 better represents what's actually happening (bugfix release) than 1.4.0, and it seems like 1.4.0 isn't a good long-term solution anyways, as the next release (1.4.1 or 1.5.0) would be cmake-only, and would break people upgrading from autotools release 1.4.0. @ilovezfs @gdsotirov Do you know if the compatibility / current version numbers reported by otool matter? If not, I'm more inclined to release 1.1.6. If they do matter, is there any workable long-term solution asides from 6.0.0? |
@pwnall Yes, because SONAME (derived form SOVERSION) is all that the dynamic linker/loader cares about, so setting CMake's SOVERSION property to
@pwnall Unfortunately, I'm not familiar with OSX and otool (shall correct this in future), but compatibility/current version numbers look weird to me like this. I presume it the best when dynamic library version matches software/project version, because it simplifies a lot of things for distribution packages and developers like me. Anyway, I more for 1.1.6 release, but you pointed out some problems with both 1.1.6 and 1.4.0, so I'm really not sure. How are the compatibility/current version numbers defined? And can this be changed, so there is no apparent downgrade after the switch to CMake? |
|
It seems most combinations you can dream up are possible: |
|
@ilovezfs Any chance you could verify that a project built against snappy 1.1.4 (i think the original bug has hadoop?) can pick up and use the snappy in your PR? Alternatively, branch rc in https://github.com/pwnall/snappy has the patch that I plan to apply to release 1.1.6. (this is still discussed internally) |
|
@pwnall testing your branch with rocksdb, before and after the change, it requires rocksdb to be rebuilt, but then it's fine. Before: After: |
The migration from autotools to CMake in 1.1.5 wasn't as smooth as intended. The SONAME / SOVERSION were broken in both build systems, causing breakages in systems that upgraded from snappy 1.1.4 to 1.1.5, as reported in Homebrew/homebrew-core#15274 and google#45.
|
@ilovezfs Thank you very much for the test results! Do you happen to know if a rebuild be required for an upgrade from 1.1.4 to 1.1.6? |
|
@pwnall yes, because with 1.1.4 the build was with Autotools, so now with 1.1.6, you get |
|
If you mean an Autotools build of 1.1.6, that currently fails If I intervene, and fix that, then the linkage ends up like this if we don't rebuild rocksdb: and |
|
(Also, I noticed that unlike the Autotools build, which installed both the dylib and static library, the CMake build only installs the dylib. That doesn't affect me personally, but there may(?) be some users who still would like the static library available.) |
|
Installing dynamic and static builds alongside each other with CMake is handled in #38. |
|
I landed this PR in 548501c. @gdsotirov @ilovezfs Thank you very much for your help! |
|
@pwnall Thanks! Homebrew/homebrew-core#15583. |
@pwnall Thanks as well! I wish you could have considered also PR #44 for 1.1.6, because it's another problem for me with 1.1.5 :-) |
|
No need for this to remain open. |
Set proper values for properties
VERSIONandSOVERSIONof targetsnappy, so that CMake produces the linklibsnappy.so.1to the shared librarylibsnappy.so.1.1.5that is built. This link was available in 1.1.4 (with autotools) and it is still necessary for the run time linker to work. Its absence leads to run time errors like "error while loading shared libraries: libsnappy.so.1: cannot open shared object file: No such file or directory".