This takes care of two of the outstanding issues in #923. One being initializing libtool with win32-dll and the other being the addition of -no-undefined to the libtool LDFLAGS. See each commit for more details.
Builders cross-compiling for Windows (including Core) will no-longer see:
libtool: warning: undefined symbols not allowed in x86_64-w64-mingw32 shared libraries; building static only
I'm planning on making some related changes downstream.
This is the recommended way to support building PE DLLs with modern
mingw toolchains and libtool.
> This option should be used if the package has been ported to build clean
> dlls on win32 platforms.
> If this macro is not used, libtool will assume that the package libraries
> are not dll clean and will build only static libraries on win32 hosts.
See:
https://www.gnu.org/software/libtool/manual/libtool.html#LT_005fINIT
https://www.gnu.org/software/gnulib/manual/html_node/Libtool-and-Windows.html
https://autotools.io/libtool/windows.html
Instruct libtool to not allow undefined symbols when linking a shared
library.
See:
https://autotools.io/libtool/windows.html
https://www.gnu.org/software/libtool/manual/libtool.html#LT_005fINIT
https://www.gnu.org/software/gnulib/manual/html_node/Libtool-and-Windows.html
Concept ACK.
ACK c0cd7de6d4e497c0e678f7098079727188e81de8
The first commit (fe32a79d354dfc7f341dbfdd6b8f0d408bd76e5b) makes LT_INIT macro perform more checks:
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... no
+checking for x86_64-w64-mingw32-as... x86_64-w64-mingw32-as
+checking for x86_64-w64-mingw32-dlltool... (cached) x86_64-w64-mingw32-dlltool
+checking for x86_64-w64-mingw32-objdump... (cached) x86_64-w64-mingw32-objdump
checking for objdir... .libs
checking if x86_64-w64-mingw32-gcc supports -fno-rtti -fno-exceptions... no
checking for x86_64-w64-mingw32-gcc option to produce PIC... -DDLL_EXPORT -DPIC
The second commit (c0cd7de6d4e497c0e678f7098079727188e81de8) makes Automake+Libtool build .libs/libsecp256k1-0.dll for --host=x86_64-w64-mingw32:
$ x86_64-w64-mingw32-nm -u .libs/libsecp256k1-0.dll
U __end__
>dumpbin /exports C:\Users\hebasto\Desktop\libsecp256k1-0.dll
Microsoft (R) COFF/PE Dumper Version 14.28.29913.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file C:\Users\hebasto\Desktop\libsecp256k1-0.dll
File Type: DLL
Section contains the following exports for libsecp256k1-0.dll
00000000 characteristics
61AB733A time date stamp Sat Dec 4 15:55:06 2021
0.00 version
1 ordinal base
39 number of functions
39 number of names
ordinal hint RVA name
1 0 0000DCD0 secp256k1_context_clone
2 1 0000DB70 secp256k1_context_create
3 2 0000DE20 secp256k1_context_destroy
4 3 00014010 secp256k1_context_no_precomp
5 4 0000DBE0 secp256k1_context_preallocated_clone
6 5 0000DA00 secp256k1_context_preallocated_clone_size
7 6 0000DA10 secp256k1_context_preallocated_create
8 7 0000DD20 secp256k1_context_preallocated_destroy
9 8 0000D9D0 secp256k1_context_preallocated_size
10 9 00012130 secp256k1_context_randomize
11 A 0000DEB0 secp256k1_context_set_error_callback
12 B 0000DE50 secp256k1_context_set_illegal_callback
13 C 000118C0 secp256k1_ec_privkey_negate
14 D 00011B30 secp256k1_ec_privkey_tweak_add
15 E 00011EA0 secp256k1_ec_privkey_tweak_mul
16 F 00010430 secp256k1_ec_pubkey_cmp
17 10 00012150 secp256k1_ec_pubkey_combine
18 11 000116A0 secp256k1_ec_pubkey_create
19 12 000118D0 secp256k1_ec_pubkey_negate
20 13 0000DFF0 secp256k1_ec_pubkey_parse
21 14 00010260 secp256k1_ec_pubkey_serialize
22 15 00011B40 secp256k1_ec_pubkey_tweak_add
23 16 00011EB0 secp256k1_ec_pubkey_tweak_mul
24 17 00011820 secp256k1_ec_seckey_negate
25 18 00011A00 secp256k1_ec_seckey_tweak_add
26 19 00011D80 secp256k1_ec_seckey_tweak_mul
27 1A 00011660 secp256k1_ec_seckey_verify
28 1B 00010E20 secp256k1_ecdsa_sign
29 1C 00010C20 secp256k1_ecdsa_signature_normalize
30 1D 000106A0 secp256k1_ecdsa_signature_parse_compact
31 1E 00010540 secp256k1_ecdsa_signature_parse_der
32 1F 00010B80 secp256k1_ecdsa_signature_serialize_compact
33 20 000107C0 secp256k1_ecdsa_signature_serialize_der
34 21 00010CE0 secp256k1_ecdsa_verify
35 22 00015480 secp256k1_nonce_function_default
36 23 00015488 secp256k1_nonce_function_rfc6979
37 24 0000DF10 secp256k1_scratch_space_create
38 25 0000DF80 secp256k1_scratch_space_destroy
39 26 00012380 secp256k1_tagged_sha256
Summary
1000 .CRT
1000 .bss
1000 .data
3000 .debug_abbrev
1000 .debug_aranges
3000 .debug_frame
4A000 .debug_info
E000 .debug_line
29000 .debug_loc
9000 .debug_ranges
1000 .debug_str
1000 .edata
1000 .idata
1000 .pdata
111000 .rdata
1000 .reloc
13000 .text
1000 .tls
1000 .xdata
Builders cross-compiling for Windows (including Core) will no-longer see:
libtool: warning: undefined symbols not allowed in x86_64-w64-mingw32 shared libraries; building static only
The warning vanished because a shared library is being built now.
utACK c0cd7de6d4e497c0e678f7098079727188e81de8. We indeed have done the work to propertly mark exported symbols, and AFAIK have no imported symbols apart from standard library ones.
FWIW, with CPPFLAGS='-D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC' linking the bench.exe fails now:
CCLD bench.exe
libtool: error: Could not determine the host path corresponding to
libtool: error: '/home/hebasto/GitHub/secp256k1/.libs'
libtool: error: Continuing, but uninstalled executables may not work.
libtool: error: Could not determine the host path corresponding to
libtool: error: '/home/hebasto/GitHub/secp256k1/.libs:/usr/local/lib:/usr/local/bin'
libtool: error: Continuing, but uninstalled executables may not work.
FWIW, with
CPPFLAGS='-D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC'linking thebench.exefails now:
I had to look those up. Just for my understanding, are you suggesting that's a problem? I think if people need this, they can still override LDFLAGS.
No, it's not a blocker for this pr which is correct.
On Sun, 5 Dec 2021 at 12:16, Tim Ruffing @.***> wrote:
FWIW, with CPPFLAGS='-D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC' linking the bench.exe fails now:
I had to look those up. Just for my understanding, are you suggesting that's a problem? I think if people need this, they can still override LDFLAGS.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/bitcoin-core/secp256k1/pull/1022#issuecomment-986202616, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH3PXPTOSWDGXVUQRB3QZ4DUPM3ZVANCNFSM5JGGOXIQ .
--
-- Hennadii Stepanov
FWIW, with
CPPFLAGS='-D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC'linking thebench.exefails now:I had to look those up. Just for my understanding, are you suggesting that's a problem? I think if people need this, they can still override LDFLAGS.
Not related to this PR (as it looks), but I'm curious why libstdc++ flags affect C code?
Not related to this PR (as it looks), but I'm curious why libstdc++ flags affect C code?
No idea, but if you're interested you could look at the diff of the preprocessor output with and without the flags. Maybe that will explain it.