bitcoin-core / secp256k1

Optimized C library for EC operations on curve secp256k1
MIT License
2.09k stars 1.01k forks source link

mingw-w64: "visibility attribute not supported in this configuration; ignored" under `-flto` #1421

Closed fanquake closed 2 weeks ago

fanquake commented 1 year ago

Building master (b10ddd2bd2bdce9ca8f2d4733636a9d9e7ac3da1):

# x86_64-w64-mingw32-gcc (GCC) 12-win32
./autogen.sh
./configure --host=x86_64-w64-mingw32 CFLAGS="-flto" LDFLAGS="-flto"
make -j9
<snip>
src/secp256k1.c: In function 'secp256k1_context_create':
src/secp256k1.c:149:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
  149 | }
      | ^
src/secp256k1.c: In function 'secp256k1_context_preallocated_clone':
src/secp256k1.c:160:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
  160 | }
      | ^
src/secp256k1.c: In function 'secp256k1_context_clone':
src/secp256k1.c:173:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
  173 | }
      | ^
src/secp256k1.c: In function 'secp256k1_context_preallocated_destroy':
src/secp256k1.c:184:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
  184 | }
      | ^
src/secp256k1.c: In function 'secp256k1_context_destroy':
src/secp256k1.c:196:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
  196 | }
      | ^
src/secp256k1.c: In function 'secp256k1_ec_pubkey_parse':
src/secp256k1.c:288:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
  288 | }
      | ^
src/secp256k1.c: In function 'secp256k1_ec_pubkey_serialize':
src/secp256k1.c:311:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
  311 | }
      | ^
< similar output continues>

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.

real-or-random commented 1 year 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.

real-or-random commented 1 year ago

cc @hebasto , any further ideas here?

hebasto commented 1 year ago

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
hebasto commented 1 year ago

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...

real-or-random commented 1 year ago

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?

real-or-random commented 2 months ago

Reported to GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116478