Closes #1136.
An example of using the check-abi.sh
tool against changes from #1140:
Concept ~0. Looks like this tool is essentially unmaintained (and only currently works with workarounds (-gdwarf-4)). There have been requests for new releases / dwarf-5 support but they haven’t gotten any response.
Are current/previous users migrating to something else?
Looks like this tool is essentially unmaintained
Correct. I’ve noticed the same. But both packages still provided in Debian repositories. And this approach is still mentioned in https://sourceware.org/glibc/wiki/Testing/ABI_checker.
7+ -DCMAKE_C_COMPILER=gcc -DCMAKE_BUILD_TYPE=None -DCMAKE_C_FLAGS="-g -Og -gdwarf-4" \
8+ -DSECP256K1_ENABLE_MODULE_ECDH=ON \
9+ -DSECP256K1_ENABLE_MODULE_RECOVERY=ON \
10+ -DSECP256K1_ENABLE_MODULE_EXTRAKEYS=ON \
11+ -DSECP256K1_ENABLE_MODULE_SCHNORRSIG=ON \
12+ -DSECP256K1_ENABLE_MODULE_ELLSWIFT=ON \
I bet that we’ll forget to update this as soon as we add the next module. I suggest using dev mode instead.
We might forget to update CMakePresets.json
as well :D
For example, it lacks SECP256K1_ENABLE_MODULE_ELLSWIFT
: https://github.com/bitcoin-core/secp256k1/blob/c545fdc374964424683d9dac31a828adedabe860/CMakePresets.json#L8-L12
I mean, that “we’ll forget to update this as soon as we add the next module” might be applied to the CMakePresets.json
as well.
And using dev mode implies building examples, which is redundant for the ABI check.
I mean, that “we’ll forget to update this as soon as we add the next module” might be applied to the
CMakePresets.json
as well.
Sure, but that doesn’t make the point invalid. I think fewer code locations that we can forget to update is still better, even if it’s not zero.
And using dev mode implies building examples, which is redundant for the ABI check.
Ok, what I had in mind is that it could still be disabled manually. But even if we don’t, it doesn’t really hurt to build the examples.
I suggest using dev mode instead.
Done.
45@@ -46,6 +46,13 @@ gcc -o ecdsa examples/ecdsa.c -I $dir/include -L $dir/lib*/ -l secp256k1 -Wl,-rp
46 * if this is not a patch release
47 * updates `_PKG_VERSION_*` and `_LIB_VERSION_*` in `configure.ac` and
48 * updates `project(libsecp256k1 VERSION ...)` and `${PROJECT_NAME}_LIB_VERSION_*` in `CMakeLists.txt`.
49+
50+ABI Compatibility must be checked with the [`check-abi.sh`](/tools/check-abi.sh) tool (installing packages `abi-dumper` and
51+ `abi-compliance-checker` might be required):
52+ ```shell
53+ tools/check-abi.sh $(git describe --abbrev=0) master
Both packages are widely available among Linux distros, including Debian and Fedora:
I have no preferences regarding the platforms to use for the ABI check. Debian works.
--match "v*.*.*"
or --first-parent
to the git command?
Weak Concept ACK
Yeah, it’s a bit sad to introduce an unmaintained tool. But this PR is just 44 LoCs, I think that’s acceptable…
My point is that checking the ABI compatibility with a dedicated tool is strictly better than an educated guess.
The suggested set of tools:
Are current/previous users migrating to something else?
I’ve made searching twice, and did not find any alternatives users are migrating to. However, I did not ask people directly, for example glibc developers.
Looks like this tool is essentially unmaintained (and only currently works with workarounds (-gdwarf-4)). There have been requests for new releases / dwarf-5 support but they haven’t gotten any response.
As this is a tool, not a dependency library, I think we can use it as long as it works regardless of its maintenance status. As far as I’m aware, there are no bugs in the tool that might affect our use case.
DWARF v4 is still well supported by the latest gcc. It is a legitimate option, not a “workaround”.
is used by other projects (for example, glibc)
The wiki you link too describes using ABI dumper on a version of glibc that is more than a decade old. Is it actually being used now? (I can’t find any use in the glibc repos). If so, I guess they aren’t maintaining those docs, as the ones listed in that wiki page wouldn’t work.
It is a legitimate option, not a “workaround”.
You are working around the fact that the tool doesn’t support DWARF 5, which is the default for modern compilers.
It is a legitimate option, not a “workaround”.
You are working around the fact that the tool doesn’t support DWARF 5, which is the default for modern compilers.
How can using DWARF v5 affect our use case?
The wiki page is indeed obsolete, so we should not count it as an argument for the tool.
But yeah, I also think -gdwarf-4
is not an issue. It’s just not the default.
This should probably have a (short) usage description when called with no arguments.
Or another idea: Have defaults for $1
and $2
. In particular, having a git describe
default for $1
would make this easier to use without looking up docs etc. Then we could have a short description when called with --help
or -h
.
Rebasing this will be good for testing. In the current branch, git describe
says that the last tag is v0.3.2. :)
I’ll add this to the upcoming milestone. If we want to have this, then it will be good to merge it before the release. @jonasnick @sipa It will be nice to have some Concept (N)ACKs here.
45@@ -46,6 +46,13 @@ gcc -o ecdsa examples/ecdsa.c -I $dir/include -L $dir/lib*/ -l secp256k1 -Wl,-rp
46 * if this is not a patch release
47 * updates `_PKG_VERSION_*` and `_LIB_VERSION_*` in `configure.ac` and
48 * updates `project(libsecp256k1 VERSION ...)` and `${PROJECT_NAME}_LIB_VERSION_*` in `CMakeLists.txt`.
49+
50+ABI Compatibility must be checked with the [`check-abi.sh`](/tools/check-abi.sh) tool (installing packages `abi-dumper` and
Why is the ABI compatibility checked between step 1 and 2? Shouldn’t this paragraph be part of the enumeration as well (and get number 2)?
But actually shouldn’t this be done before updating the version number and writing the release notes?
check-abi.sh
appear to work as intended. abi-dumper
and abi-compliance-checker
are available on NixOS. I think this can be a helpful addition to the release process at the cost of adding a small shell script.
Rebasing this will be good for testing. In the current branch,
git describe
says that the last tag is v0.3.2. :)
Rebased. @jonasnick’s comment has been addressed.
36@@ -37,7 +37,11 @@ gcc -o ecdsa examples/ecdsa.c -I $dir/include -L $dir/lib*/ -l secp256k1 -Wl,-rp
37
38 ## Regular release
39
40-1. Open a PR to the master branch with a commit (using message `"release: prepare for $MAJOR.$MINOR.$PATCH"`, for example) that
41+1. Check the ABI compatibility with the [`check-abi.sh`](/tools/check-abi.sh) tool (installing the `abi-dumper` and `abi-compliance-checker` packages might be required):
42+```shell
43+tools/check-abi.sh
44+```
nit: how about we move this to the sanity checks section since it’s also relevant for maintenance releases:
04. Use the [`check-abi.sh`](/tools/check-abi.sh) tool to ensure there are no unexpected ABI incompatibilities and that the version number and release notes accurately reflect all potential ABI changes. To run this tool, the `abi-dumper` and `abi-compliance-checker` packages are required.
1
2\```shell
3tools/check-abi.sh
4\```
ACK 09f9472879277d3c335e7a00741b407c4bc35dcf Tested and works nicely :)
I’m happy to reACK quickly this with my suggestion applied, but I’m also happy to get this merged as-is for the release
57+cd "$current_build_dir"
58+configure_and_build "$source_dir"
59+abi-dumper src/libsecp256k1.so -o ABI.dump -lver "$new_version"
60+cd "$source_dir"
61+
62+abi-compliance-checker -lib libsecp256k1 -old "${base_build_dir}/ABI.dump" -new "${current_build_dir}/ABI.dump"
Here’s a change that uses also temporary source trees (instead of just build trees):
0checkout_and_build() {
1 git worktree add -d "$1"
2 cd "$1"
3 mkdir build && cd build
4 cmake -S .. --preset dev-mode \
5 -DCMAKE_C_COMPILER=gcc -DCMAKE_BUILD_TYPE=None -DCMAKE_C_FLAGS="-g -Og -gdwarf-4" \
6 -DSECP256K1_BUILD_BENCHMARK=OFF \
7 -DSECP256K1_BUILD_TESTS=OFF \
8 -DSECP256K1_BUILD_EXHAUSTIVE_TESTS=OFF \
9 -DSECP256K1_BUILD_CTIME_TESTS=OFF \
10 -DSECP256K1_BUILD_EXAMPLES=OFF
11 cmake --build . -j "$(nproc)"
12}
13
14echo "Comparing $base_version (base version) to $new_version (new version)"
15echo
16
17base_source_dir=$(mktemp -d)
18checkout_and_build "$base_source_dir"
19abi-dumper src/libsecp256k1.so -o ABI.dump -lver "$base_version"
20
21current_source_dir=$(mktemp -d)
22checkout_and_build "$current_source_dir"
23abi-dumper src/libsecp256k1.so -o ABI.dump -lver "$new_version"
24
25abi-compliance-checker -lib libsecp256k1 -old "${base_source_dir}/build/ABI.dump" -new "${current_source_dir}/build/ABI.dump"
Do you mean this one?
Sorry, I meant the one I’ve just posted now… :D (Sorry, not sure if this got lost in transit, or if I just forgot to click the “Comment” button…)
Argh, sorry -.-
I think we’ll need to add the git revision as an arg to git worktree add -d "$1"
, like git worktree add -d "$1" <tag>
.. And then move the git worktree
command out of the function again… I can look into it later, but I don’t have the time right now.
Co-authored-by: Tim Ruffing <crypto@timruffing.de>
Fixed minor issues in the recent implementation.
Suggesting to test by running tools/check-abi.sh v0.3.2 v0.4.0
. The resulted report must be the same as in #1415 (comment).
re-Concept ACK 74a4d974d5c81fbc437287dffc453028509682ab
The tool continues to work for me.