build: avoid exporting secp256k1 symbols

theuni commented at 9:29 pm on February 10, 2026: member

Take advantage of the new secp256k1 option to avoid visibility attributes on API functions.

While most users of a shared libsecp always want API functions exported so that they can actually be linked against, we always build it statically. When that static lib is linked into a (static or shared) libbitcoinkernel, by default its symbols end up exported there as well.

As libsecp is an implementation detail of the kernel (and any future Core lib), its symbols should never be exported.

This was the intended use for the above PR, looks like we just forgot to follow-up and actually hook it up.

This is most easily tested by building with -DBUILD_KERNEL_LIB=ON -DBUILD_SHARED_LIBS=ON (with or without -DREDUCE_EXPORTS=ON) and inspecting via:

0nm -CD lib/libbitcoinkernel.so | grep secp

Before this change, secp’s symbols will show up there. After, they should be absent.

This should finally solve secp symbol visibility once and for all :)

build: avoid exporting secp256k1 symbols

Take advantage of the new secp256k1 option to avoid visibility attributes on
API functions.

While most users of a shared libsecp always want API functions exported so that
they can actually be linked against, we always build it statically. When that
static lib is linked into a (static or shared) libbitcoinkernel, by default its
symbols end up exported there as well.

As libsecp is an implementation detail of the kernel (and any future Core lib),
its symbols should never be exported.

2ccfdb582b

DrahtBot added the label Build system on Feb 10, 2026

DrahtBot commented at 9:29 pm on February 10, 2026: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	hebasto, stickies-v

If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.

hebasto commented at 0:06 am on February 11, 2026: member

Concept ACK.

in cmake/secp256k1.cmake:15 in 2ccfdb582b

 8@@ -9,6 +9,11 @@ function(add_secp256k1 subdir)
 9   message("Configuring secp256k1 subtree...")
10   set(BUILD_SHARED_LIBS OFF)
11   set(CMAKE_EXPORT_COMPILE_COMMANDS OFF)
12+
13+  # Unconditionally prevent secp's symbols from being exported by our libs
14+  set(CMAKE_C_VISIBILITY_PRESET hidden)
15+  set(SECP256K1_ENABLE_API_VISIBILITY_ATTRIBUTES OFF CACHE BOOL "" FORCE)

hebasto commented at 0:33 am on February 11, 2026:

Unrelated, but at some point we might want to convert these SECP256K1_* variables into non-cache variables, as they are not intended to be modified by users.

theuni commented at 1:59 pm on February 11, 2026:

Heh, I struggled while adding another one of these, trying to decide if it should just fit with the existing options or do the more correct thing. I went with the former with the intention of fixing them all up together later.

Agreed, these shouldn’t be exposed to users.

hebasto approved

hebasto commented at 0:33 am on February 11, 2026: member

ACK 2ccfdb582b646d9bda07f0f13b97cb8c37a452aa, this is implemented exactly as I tested the upstream PR. Tested on Fedora 43.

?

added_to_project_v2 fanquake

?

project_v2_item_status_changed github-project-automation[bot]

stickies-v commented at 12:08 pm on February 11, 2026: contributor

Concept ACK

in cmake/secp256k1.cmake:14 in 2ccfdb582b

 8@@ -9,6 +9,11 @@ function(add_secp256k1 subdir)
 9   message("Configuring secp256k1 subtree...")
10   set(BUILD_SHARED_LIBS OFF)
11   set(CMAKE_EXPORT_COMPILE_COMMANDS OFF)
12+
13+  # Unconditionally prevent secp's symbols from being exported by our libs
14+  set(CMAKE_C_VISIBILITY_PRESET hidden)

stickies-v commented at 1:02 pm on February 11, 2026:

I think this remains in function scope, so it’s probably only a stylistic change, but we could avoid overriding this global variable and make it target based instead?

 0diff --git a/cmake/secp256k1.cmake b/cmake/secp256k1.cmake
 1index c82f361aba..05cd7a3d49 100644
 2--- a/cmake/secp256k1.cmake
 3+++ b/cmake/secp256k1.cmake
 4@@ -11,7 +11,6 @@ function(add_secp256k1 subdir)
 5   set(CMAKE_EXPORT_COMPILE_COMMANDS OFF)
 6 
 7   # Unconditionally prevent secp's symbols from being exported by our libs
 8-  set(CMAKE_C_VISIBILITY_PRESET hidden)
 9   set(SECP256K1_ENABLE_API_VISIBILITY_ATTRIBUTES OFF CACHE BOOL "" FORCE)
10 
11   set(SECP256K1_ENABLE_MODULE_ECDH OFF CACHE BOOL "" FORCE)
12@@ -52,6 +51,7 @@ function(add_secp256k1 subdir)
13 
14   add_subdirectory(${subdir})
15   set_target_properties(secp256k1 PROPERTIES
16+    C_VISIBILITY_PRESET hidden
17     EXCLUDE_FROM_ALL TRUE
18   )
19 endfunction()

hebasto commented at 1:09 pm on February 11, 2026:

In that case, the C_VISIBILITY_PRESET property won’t be propagated to the sub-targets, which are essentially libsecp256k1 build system implementation details subject to change.

theuni commented at 1:56 pm on February 11, 2026:

Yeah, the function scope was purposeful so we’re covered in the future. As long as BUILD_SHARED_LIBS is scoped here, hidden visibility and disabled visibility attributes are safe in the same scope.

stickies-v approved

stickies-v commented at 1:04 pm on February 11, 2026: contributor

tACK 2ccfdb582b646d9bda07f0f13b97cb8c37a452aa

Tested on mac with -DREDUCE_EXPORTS ON and OFF:

0% nm -gC ./build/lib/libbitcoinkernel.dylib | grep -i secp
100000000000c3d80 T ecdsa_signature_parse_der_lax(secp256k1_ecdsa_signature*, unsigned char const*, unsigned long)

fanquake merged this on Feb 11, 2026

fanquake closed this on Feb 11, 2026

?

project_v2_item_status_changed github-project-automation[bot]

build: avoid exporting secp256k1 symbols #34554

Reviews