WIP: visibility example for cmake #1695

1. 
   purpleKarrot commented at 5:08 pm on June 30, 2025: contributor

   Alternative to #1674 and #1677.
2. purpleKarrot force-pushed on Jun 30, 2025
3. 
   purpleKarrot commented at 5:34 pm on June 30, 2025: contributor

   The fact that a build called “Windows (VS 2022, static)” is failing with the message “unresolved external symbol __imp_…” is concerning. The fact that private symbols cannot be resolved indicates that visibility is working correctly and that the library is not static. Unfortunately, the compiler command line is not visible on github, so this needs further investigation.
4. 
   real-or-random commented at 6:22 am on July 1, 2025: contributor

   The fact that private symbols cannot be resolved indicates (…) that the library is not static.

   I don’t think so. It builds a “.lib” file: https://github.com/bitcoin-core/secp256k1/actions/runs/15979380201/job/45069998808?pr=1695#step:4:57

   See also https://github.com/bitcoin-core/secp256k1/actions/runs/15965328923/job/45024576152#step:5:36, which shows that no “.dll” is created on master. (We should run file also on “*.lib” files…)

5. 
   real-or-random commented at 6:49 am on July 1, 2025: contributor

   I suspect that building the exes fails because SECP256K1_STATIC is not actually set for some reason.

   Unfortunately, the compiler command line is not visible on github, so this needs further investigation.

   Yes, adding this to CI would be useful in any case.

6. 
   purpleKarrot commented at 8:33 am on July 1, 2025: contributor

   The fact that private symbols cannot be resolved indicates (…) that the library is not static.

   I don’t think so. It builds a “.lib” file: https://github.com/bitcoin-core/secp256k1/actions/runs/15979380201/job/45069998808?pr=1695#step:4:57

   I don’t find that convincing.

   0Creating library D:/a/secp256k1/secp256k1/build/lib/RelWithDebInfo/noverify_tests.lib and object D:/a/secp256k1/secp256k1/build/lib/RelWithDebInfo/noverify_tests.exp
   1  noverify_tests.vcxproj -> D:\a\secp256k1\secp256k1\build\bin\RelWithDebInfo\noverify_tests.exe
   2  secp256k1.vcxproj -> D:\a\secp256k1\secp256k1\build\lib\RelWithDebInfo\libsecp256k1.lib
   

   This does not indicate that a static library for libsecp256k1 is created, it just means that noverify_tests links against libsecp256k1.lib, which could be a static library or an import library for an associated .dll. Both of these have the same file extension.

7. 
   real-or-random commented at 8:49 am on July 1, 2025: contributor

   Ok, maybe this is more convincing:

   • This output line from the “shared” job on master mentions the dll explicitly: https://github.com/bitcoin-core/secp256k1/actions/runs/15965328923/job/45024576149#step:4:53
   • (Same for the “shared” job in this PR: https://github.com/bitcoin-core/secp256k1/actions/runs/15979380201/job/45069998798?pr=1695#step:4:56)
   • But the corresponding output line from the “static” job doesn’t mention the dll: https://github.com/bitcoin-core/secp256k1/actions/runs/15979380201/job/45069998808?pr=1695#step:4:57
8. purpleKarrot force-pushed on Jul 1, 2025
9. purpleKarrot force-pushed on Jul 1, 2025
10. 
    purpleKarrot commented at 10:26 am on July 1, 2025: contributor

    I see the issue. The usage requirements of the secp256k1 target are not applied, because benchmarks and tests don’t actually build against that target. They build against secp256k1_precomputed and secp256k1_asm instead.
11. purpleKarrot force-pushed on Jul 1, 2025
12. purpleKarrot force-pushed on Jul 1, 2025
13. WIP: visibility example for cmake aa8c67f148
14. purpleKarrot force-pushed on Jul 1, 2025
15. 
    theuni commented at 2:07 pm on July 1, 2025: contributor

    A few things:

    1. As discussed in the other PRs, it’s clear that this would be much simpler if we only supported CMake, but that’s unfortunately not the reality at the moment. The majority of the cruft in the header exists to support the combination of buildsystems.
    2. Could you please split this into refactor vs behavioral change commits for easier review? There’s a lot going on here and the some of the rationale isn’t obvious at first glimpse.
16. 
    real-or-random commented at 10:31 am on July 2, 2025: contributor

    If we don’t use this approach in the end, we should recycle the CMake snippets code that sets SECP256K1_STATIC for the parent when consuming the library.
17. real-or-random added the label feature on Jul 2, 2025
18. real-or-random added the label build on Jul 2, 2025

Contributors
purpleKarrot real-or-random theuni

Labels
feature build