Closed fanquake closed 2 weeks ago
Hm, thanks. It's a bit mysterious that this happens only with -flto
and only when compiling tests or noverify_tests, but for example not in the exhaustive_tests. But okay, whatever, apparently we hit that line here, which is supposed to be active only when not on Windows:
https://github.com/bitcoin-core/secp256k1/blob/b10ddd2bd2bdce9ca8f2d4733636a9d9e7ac3da1/include/secp256k1.h#L159-L161
We should probably just have a SECP256K1_TESTS
#define and if this is defined, set nothing for symbol visibility.
cc @hebasto , any further ideas here?
cc @hebasto , any further ideas here?
I'm looking into it.
Just a note about building with LTO using CMake:
cmake -B build -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON --toolchain cmake/x86_64-w64-mingw32.toolchain.cmake
cmake --build build
The -flto-partition=1to1
option helps:
$ x86_64-w64-mingw32-gcc --version
x86_64-w64-mingw32-gcc (GCC) 12-posix
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ./autogen.sh
$ ./configure --host=x86_64-w64-mingw32 CFLAGS="-flto -flto-partition=1to1" LDFLAGS="-flto=auto"
$ make -j16
From GCC docs:
...‘1to1’ can be used as an workaround for various code ordering issues...
The
-flto-partition=1to1
option helps:
Hm, interesting and good to know. I guess, we should still make sure the build is clean with just -lto
. Any suggestions here?
Reported to GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116478
Building master (b10ddd2bd2bdce9ca8f2d4733636a9d9e7ac3da1):
Wanted to raise this, as Core may eventually go down the LTO route (https://github.com/bitcoin/bitcoin/pull/25391), and
-flto
will be getting passed down.