This change emulates Libtool to make sure Libtool and CMake agree on the ABI version.
To test, one needs to simulate a release with backward-compatible API changes, which means the following changes in configure.ac and CMakeLists.txt:
*_LIB_VERSION_CURRENT*_LIB_VERSION_REVISION to zero*_LIB_VERSION_AGE
Sorry, I lost context here a bit. Can you explain again what the issue is and how it’s fixed?
0diff --git a/CMakeLists.txt b/CMakeLists.txt
1index a70165e..8216bad 100644
2--- a/CMakeLists.txt
3+++ b/CMakeLists.txt
4@@ -17,9 +17,9 @@ project(libsecp256k1 VERSION 0.3.2 LANGUAGES C)
5 # https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
6 # All changes in experimental modules are treated as if they don't affect the
7 # interface and therefore only increase the revision.
8-set(${PROJECT_NAME}_LIB_VERSION_CURRENT 2)
9-set(${PROJECT_NAME}_LIB_VERSION_REVISION 2)
10-set(${PROJECT_NAME}_LIB_VERSION_AGE 0)
11+set(${PROJECT_NAME}_LIB_VERSION_CURRENT 3)
12+set(${PROJECT_NAME}_LIB_VERSION_REVISION 0)
13+set(${PROJECT_NAME}_LIB_VERSION_AGE 1)
14
15 set(CMAKE_C_STANDARD 90)
16 set(CMAKE_C_EXTENSIONS OFF)
17diff --git a/configure.ac b/configure.ac
18index 0b555ea..acb923e 100644
19--- a/configure.ac
20+++ b/configure.ac
21@@ -13,9 +13,9 @@ define(_PKG_VERSION_IS_RELEASE, false)
22 # https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
23 # All changes in experimental modules are treated as if they don't affect the
24 # interface and therefore only increase the revision.
25-define(_LIB_VERSION_CURRENT, 2)
26-define(_LIB_VERSION_REVISION, 2)
27-define(_LIB_VERSION_AGE, 0)
28+define(_LIB_VERSION_CURRENT, 3)
29+define(_LIB_VERSION_REVISION, 0)
30+define(_LIB_VERSION_AGE, 1)
31
32 AC_INIT([libsecp256k1],m4_join([.], _PKG_VERSION_MAJOR, _PKG_VERSION_MINOR, _PKG_VERSION_PATCH)m4_if(_PKG_VERSION_IS_RELEASE, [true], [], [-dev]),[https://github.com/bitcoin-core/secp256k1/issues],[libsecp256k1],[https://github.com/bitcoin-core/secp256k1])
33
0$ ./autogen.sh && ./configure && make
1$ ls -1 .libs/libsecp256k1.so.*
2.libs/libsecp256k1.so.2
3.libs/libsecp256k1.so.2.1.0
0$ cmake -S . -B build && cmake --build build
1$ ls -1 build/src/libsecp256k1.so.*
2build/src/libsecp256k1.so.3
3build/src/libsecp256k1.so.3.1.0
Can you add a comment that says that this emulates libtool, something like,
0 This emulates libtool to make sure libtool and cmake agree on the ABI version,
1 see below "Calculate the version variables" in build-aux/ltmain.sh.
(quicklink here for any readers here who don’t want to look it up: https://github.com/autotools-mirror/libtool/blob/1ec8fa28dcb29500d485c136db28315671ec4c3b/build-aux/ltmain.in#L7002 )
The problem I see here is that libtool’s logic depends on the OS… :/
So, I think the changes here correctly emulate libtools on Linux. Have you checked this against libtool on MacOS too (including the -current_version and -compatibility_version passed to the linker)? Do we care about Windows? I guess there’s anyway no fixed versioning scheme on Windows, so it probably won’t matter.
Related: https://cmake.org/cmake/help/latest/prop_tgt/SOVERSION.html
Have you checked this against libtool on MacOS too (including the
-current_versionand-compatibility_versionpassed to the linker)?
Checked. It doesn’t look right. Investigating…
Do we care about Windows?
I’ve noticed this issue while working on Windows stuff :)
Have you checked this against libtool on MacOS too (including the
-current_versionand-compatibility_versionpassed to the linker)?Checked. It doesn’t look right. Investigating…
To make versioning 100%-compatible with Libtool’s scheme for macOS, MACHO_COMPATIBILITY_VERSION and MACHO_CURRENT_VERSION are required, but they are available in CMake 3.17+ only.
UPD. Here are similar issues in other projects:
Rebased on top of the bitcoin-core/secp256k1#1230.
The problem I see here is that libtool’s logic depends on the OS… :/
I’ve limited this PR to Linux platform explicitly, leaving other platforms discussion for follow ups.
Can you add a comment that says that this emulates libtool, something like,
0 This emulates libtool to make sure libtool and cmake agree on the ABI version, 1 see below "Calculate the version variables" in build-aux/ltmain.sh.
Thanks! Added.
I’ve limited this PR to Linux platform explicitly, leaving other platforms discussion for follow ups.
Concept ACK, but I fail to see how the current diff affects Linux only
Given that you looked into this, what would you recommend for other problems? I think we could make it work on CMake 3.17+ and perhaps output a warning on lower versions (or document it somewhere else)? What about Windows?
I’ve limited this PR to Linux platform explicitly, leaving other platforms discussion for follow ups.
Concept ACK, but I fail to see how the current diff affects Linux only
Given that you looked into this, what would you recommend for other problems? I think we could make it work on CMake 3.17+ and perhaps output a warning on lower versions (or document it somewhere else)? What about Windows?
Reworked to be applied for all supported target platforms.
Added a warning if the user is going to build macOS DYLIB using CMake < 3.17.
45 )
46+if(CMAKE_SYSTEM_NAME STREQUAL "Linux")
47+ set_target_properties(secp256k1 PROPERTIES
48+ VERSION ${${PROJECT_NAME}_soversion}.${${PROJECT_NAME}_LIB_VERSION_AGE}.${${PROJECT_NAME}_LIB_VERSION_REVISION}
49+ )
50+elseif(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
0elseif(APPLE)
Would this make a difference? (If not, I’m not sure if it’s better ^^.)
From CMake docs:
APPLE
Set to True when the target system is an Apple platform (macOS, iOS, tvOS or watchOS).
APPLE != OSX. Can we narrow this down some?
Concept ACK.
It’s frustrating that they differ. Also, note that this is a case where a user gets worse binaries with older CMake, but I’m not sure we can do anything about that.
@hebasto How confident are you about macOS and Windows?
Tested once more with the following diff:
0diff --git a/CMakeLists.txt b/CMakeLists.txt
1index 91d2bed..22706d3 100644
2--- a/CMakeLists.txt
3+++ b/CMakeLists.txt
4@@ -17,9 +17,9 @@ project(libsecp256k1 VERSION 0.3.2 LANGUAGES C)
5 # https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
6 # All changes in experimental modules are treated as if they don't affect the
7 # interface and therefore only increase the revision.
8-set(${PROJECT_NAME}_LIB_VERSION_CURRENT 2)
9-set(${PROJECT_NAME}_LIB_VERSION_REVISION 2)
10-set(${PROJECT_NAME}_LIB_VERSION_AGE 0)
11+set(${PROJECT_NAME}_LIB_VERSION_CURRENT 1000)
12+set(${PROJECT_NAME}_LIB_VERSION_REVISION 100)
13+set(${PROJECT_NAME}_LIB_VERSION_AGE 10)
14
15 set(CMAKE_C_STANDARD 90)
16 set(CMAKE_C_EXTENSIONS OFF)
17diff --git a/configure.ac b/configure.ac
18index 0b555ea..08d9b64 100644
19--- a/configure.ac
20+++ b/configure.ac
21@@ -13,9 +13,9 @@ define(_PKG_VERSION_IS_RELEASE, false)
22 # https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
23 # All changes in experimental modules are treated as if they don't affect the
24 # interface and therefore only increase the revision.
25-define(_LIB_VERSION_CURRENT, 2)
26-define(_LIB_VERSION_REVISION, 2)
27-define(_LIB_VERSION_AGE, 0)
28+define(_LIB_VERSION_CURRENT, 1000)
29+define(_LIB_VERSION_REVISION, 100)
30+define(_LIB_VERSION_AGE, 10)
31
32 AC_INIT([libsecp256k1],m4_join([.], _PKG_VERSION_MAJOR, _PKG_VERSION_MINOR, _PKG_VERSION_PATCH)m4_if(_PKG_VERSION_IS_RELEASE, [true], [], [-dev]),[https://github.com/bitcoin-core/secp256k1/issues],[libsecp256k1],[https://github.com/bitcoin-core/secp256k1])
33
On macOS:
0% ./autogen.sh && ./configure --disable-static
1% make
2% ls -l .libs/*dylib*
3-rwxr-xr-x 1 hebasto staff 1361344 Apr 28 19:58 .libs/libsecp256k1.990.dylib
4lrwxr-xr-x 1 hebasto staff 22 Apr 28 19:58 .libs/libsecp256k1.dylib -> libsecp256k1.990.dylib
5% otool -L .libs/libsecp256k1.dylib
6.libs/libsecp256k1.dylib:
7 /usr/local/lib/libsecp256k1.990.dylib (compatibility version 1001.0.0, current version 1001.100.0)
8 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
0% cmake -S . -B build
1% cmake --build build
2% ls -l build/src/*dylib*
3-rwxr-xr-x 1 hebasto staff 1361320 Apr 28 20:00 build/src/libsecp256k1.990.dylib
4lrwxr-xr-x 1 hebasto staff 22 Apr 28 20:00 build/src/libsecp256k1.dylib -> libsecp256k1.990.dylib
5% otool -L build/src/libsecp256k1.dylib
6build/src/libsecp256k1.dylib: [@rpath](/bitcoin-core-secp256k1/contributor/rpath/)/libsecp256k1.990.dylib (compatibility version 1001.0.0, current version 1001.100.0)
7 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
A minor issue has been noted when cross-building for Windows. Going to address it shortly. @real-or-random
I think this is ready for merge.
Let’s fix and test the issue for Windows first :)
Updated 5a730304c55d77f377072993f9c76688a9f19246 -> d2e4e18a1ab7761282a24e90b1a77d10af3c2de8 (pr1270.05 -> pr1270.06, diff):
On Ubuntu 23.04 (with the diff from #1270 (comment)):
0$ ./autogen.sh && ./configure --host=x86_64-w64-mingw32 --disable-static
1$ ./configure --disable-static --host=x86_64-w64-mingw32
2$ make
3$ ls -1 .libs/*dll*
4.libs/libsecp256k1-990.dll
5.libs/libsecp256k1.dll.a
0$ cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=cmake/x86_64-w64-mingw32.toolchain.cmake
1$ cmake --build build
2$ ls -1 build/src/*dll*
3build/src/libsecp256k1-990.dll
4build/src/libsecp256k1.dll.a
Not able to test native builds on Windows right now…
This change emulates Libtool to make sure Libtool and CMake agree on the
ABI version.
Updated d2e4e18a1ab7761282a24e90b1a77d10af3c2de8 -> bef448f9af248dba016883401de07b431f3e686e (pr1270.06 -> pr1270.07, diff):
How confident are you about macOS and Windows?
100%
If you’ve tested on these platforms, I think this is ready for merge.
I’ve tested cross-compiling for Windows and native builds on macOS and on Windows.
64+ endif()
65+elseif(CMAKE_SYSTEM_NAME STREQUAL "Windows")
66+ set(${PROJECT_NAME}_windows "secp256k1")
67+ if(MSVC)
68+ set(${PROJECT_NAME}_windows "${PROJECT_NAME}")
69+ endif()
67+ if(MSVC)
68+ set(${PROJECT_NAME}_windows "${PROJECT_NAME}")
69+ endif()
70+ set_target_properties(secp256k1 PROPERTIES
71+ ARCHIVE_OUTPUT_NAME "${${PROJECT_NAME}_windows}"
72+ RUNTIME_OUTPUT_NAME "${${PROJECT_NAME}_windows}-${${PROJECT_NAME}_soversion}"
DLL_NAME_WITH_SOVERSION on the same purpose.