Another issue with the current implementation is that the examples cannot run individually on Windows.
This PR resolves both issues by reverting the implementation from #1290 in favour of the reworked and improved implementation from #1233.
real-or-random added the label
assurance
on Jun 26, 2024
real-or-random added the label
build
on Jun 26, 2024
real-or-random removed the label
assurance
on Jun 26, 2024
real-or-random
commented at 9:26 am on June 26, 2024:
contributor
ACK3779472074d29125c06b715787005f3ac4f95cdf
It’s probably a good idea that the binaries just work without the need to set a PATH. And it’s okay to collect all binary artifacts in a single directory, we don’t have that many.
real-or-random
commented at 9:26 am on June 26, 2024:
contributor
What are your commands for building on wine?
hebasto
commented at 10:19 am on June 26, 2024:
member
What are your commands for building on wine?
On Ubuntu 24.04 with the wine-binfmt package installed:
0$ cmake -B build --toolchain cmake/x86_64-w64-mingw32.toolchain.cmake -DSECP256K1_BUILD_EXAMPLES=ON
1$ cmake --build build
2$ ctest --test-dir build
3Internal ctest changing into directory: /home/hebasto/git/secp256k1/secp256k1/build
4Test project /home/hebasto/git/secp256k1/secp256k1/build
5 Start 1: noverify_tests
61/6 Test [#1](/bitcoin-core-secp256k1/1/): noverify_tests ................... Passed 52.72 sec 7 Start 2: tests
82/6 Test [#2](/bitcoin-core-secp256k1/2/): tests ............................ Passed 111.58 sec 9 Start 3: exhaustive_tests
103/6 Test [#3](/bitcoin-core-secp256k1/3/): exhaustive_tests ................. Passed 8.01 sec11 Start 4: ecdsa_example
124/6 Test [#4](/bitcoin-core-secp256k1/4/): ecdsa_example .................... Passed 1.35 sec13 Start 5: ecdh_example
145/6 Test [#5](/bitcoin-core-secp256k1/5/): ecdh_example ..................... Passed 1.34 sec15 Start 6: schnorr_example
166/6 Test [#6](/bitcoin-core-secp256k1/6/): schnorr_example .................. Passed 1.32 sec1718100% tests passed, 0 tests failed out of 61920Total Test time (real) =176.31 sec
21$./build/bin/schnorr_example.exe
22Is the signature valid? true
23Secret Key: 0x964362f6515fbb691dee49b936c8ba46dadd505eb4aa27f5db9b1ccf510f04a824Public Key: 0x286123fee26ecfc75ec8bd6d4e175a9b4fa729e7d2bcd4034661a33dee600d8025Signature: 0xef0aa23ae13fd06710e31204a7a8ab52f0b726159b3cb2344c090220ed32d6dda958c9f7b3383c3fa7524a7f7ed54bf381c8a3bab1f8561072887dae6bf7bfe1
fanquake
commented at 2:50 pm on June 26, 2024:
member
This change:
1. Collects build artifacts in dedicated locations.
2. Allows to run individual examples with a shared library on Windows.
3. Is compatible with Wine when testing cross-compiled Windows binaries
on Linux.
4. Is compatible with integration the project into a larger project
hierarchy.
26e4a7c214
Revert "cmake: Set `ENVIRONMENT` property for examples on Windows"
This reverts commit 116d2ab3df630455f23a7b21f50237689879ecc0.
c232486d84
hebasto force-pushed
on Sep 18, 2024
hebasto
commented at 5:15 pm on September 18, 2024:
member
Rebased.
theuni
commented at 8:27 pm on September 18, 2024:
contributor
I’m not sure what I’m missing here. Why does moving from src/ to bin/ fix anything? And mirroring the source tree is kinda the convention for CMake, no? I’d expect to find them in src/ anyway.
hebasto
commented at 7:43 am on September 19, 2024:
member
Why does moving from src/ to bin/ fix anything?
Moving built binaries from both src/ and example/ to bin/ does fix the issue because it places the executable and its dependency DLL in the same folder.
FWIW, we have a similar issue with the libbitcoinkernel shared library in Bitcoin Core.
And mirroring the source tree is kinda the convention for CMake, no?
It’s the default behaviour adopted by many projects. However, here is a code snippet from the LLVM project:
A common use of these target properties is to collect libraries and executables together in a similar directory structure as they would have when installed. This is helpful if applications expect various resources to be located at a particular location relative to the executable’s binary. On Windows, it can also simplify debugging, since executables and DLLs can be collected into the same directory, allowing the executables to find their DLL dependencies automatically (this isn’t needed on other platforms, since RPATH support embeds the necessary locations in the binaries themselves).
theuni
commented at 5:51 pm on September 19, 2024:
contributor
Ok, I see. I think (from googling) the part that I was missing is that dll’s are put in CMAKE_RUNTIME_OUTPUT_DIRECTORY rather than CMAKE_LIBRARY_OUTPUT_DIRECTORY as I would’ve expected. Is that correct?
For Linux at least, .so’s go to CMAKE_LIBRARY_OUTPUT_DIRECTORY.
real-or-random
commented at 8:31 am on September 20, 2024:
contributor
Ok, I see. I think (from googling) the part that I was missing is that dll’s are put in CMAKE_RUNTIME_OUTPUT_DIRECTORY rather than CMAKE_LIBRARY_OUTPUT_DIRECTORY as I would’ve expected. Is that correct?
On non-DLL platforms: the shared library file (e.g. .so or .dylib) of a shared library target created by the add_library() command with the SHARED option.
This is a metadata mirror of the GitHub repository
bitcoin-core/secp256k1.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2025-07-29 23:15 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me