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:
0libtool: 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
ACK c0cd7de6d4e497c0e678f7098079727188e81de8
The first commit (fe32a79d354dfc7f341dbfdd6b8f0d408bd76e5b) makes LT_INIT macro perform more checks:
0 checking for stdint.h... yes
1 checking for unistd.h... yes
2 checking for dlfcn.h... no
3+checking for x86_64-w64-mingw32-as... x86_64-w64-mingw32-as
4+checking for x86_64-w64-mingw32-dlltool... (cached) x86_64-w64-mingw32-dlltool
5+checking for x86_64-w64-mingw32-objdump... (cached) x86_64-w64-mingw32-objdump
6 checking for objdir... .libs
7 checking if x86_64-w64-mingw32-gcc supports -fno-rtti -fno-exceptions... no
8 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:
0$ x86_64-w64-mingw32-nm -u .libs/libsecp256k1-0.dll
1 U __end__
0>dumpbin /exports C:\Users\hebasto\Desktop\libsecp256k1-0.dll
1Microsoft (R) COFF/PE Dumper Version 14.28.29913.0
2Copyright (C) Microsoft Corporation. All rights reserved.
3
4
5Dump of file C:\Users\hebasto\Desktop\libsecp256k1-0.dll
6
7File Type: DLL
8
9 Section contains the following exports for libsecp256k1-0.dll
10
11 00000000 characteristics
12 61AB733A time date stamp Sat Dec 4 15:55:06 2021
13 0.00 version
14 1 ordinal base
15 39 number of functions
16 39 number of names
17
18 ordinal hint RVA name
19
20 1 0 0000DCD0 secp256k1_context_clone
21 2 1 0000DB70 secp256k1_context_create
22 3 2 0000DE20 secp256k1_context_destroy
23 4 3 00014010 secp256k1_context_no_precomp
24 5 4 0000DBE0 secp256k1_context_preallocated_clone
25 6 5 0000DA00 secp256k1_context_preallocated_clone_size
26 7 6 0000DA10 secp256k1_context_preallocated_create
27 8 7 0000DD20 secp256k1_context_preallocated_destroy
28 9 8 0000D9D0 secp256k1_context_preallocated_size
29 10 9 00012130 secp256k1_context_randomize
30 11 A 0000DEB0 secp256k1_context_set_error_callback
31 12 B 0000DE50 secp256k1_context_set_illegal_callback
32 13 C 000118C0 secp256k1_ec_privkey_negate
33 14 D 00011B30 secp256k1_ec_privkey_tweak_add
34 15 E 00011EA0 secp256k1_ec_privkey_tweak_mul
35 16 F 00010430 secp256k1_ec_pubkey_cmp
36 17 10 00012150 secp256k1_ec_pubkey_combine
37 18 11 000116A0 secp256k1_ec_pubkey_create
38 19 12 000118D0 secp256k1_ec_pubkey_negate
39 20 13 0000DFF0 secp256k1_ec_pubkey_parse
40 21 14 00010260 secp256k1_ec_pubkey_serialize
41 22 15 00011B40 secp256k1_ec_pubkey_tweak_add
42 23 16 00011EB0 secp256k1_ec_pubkey_tweak_mul
43 24 17 00011820 secp256k1_ec_seckey_negate
44 25 18 00011A00 secp256k1_ec_seckey_tweak_add
45 26 19 00011D80 secp256k1_ec_seckey_tweak_mul
46 27 1A 00011660 secp256k1_ec_seckey_verify
47 28 1B 00010E20 secp256k1_ecdsa_sign
48 29 1C 00010C20 secp256k1_ecdsa_signature_normalize
49 30 1D 000106A0 secp256k1_ecdsa_signature_parse_compact
50 31 1E 00010540 secp256k1_ecdsa_signature_parse_der
51 32 1F 00010B80 secp256k1_ecdsa_signature_serialize_compact
52 33 20 000107C0 secp256k1_ecdsa_signature_serialize_der
53 34 21 00010CE0 secp256k1_ecdsa_verify
54 35 22 00015480 secp256k1_nonce_function_default
55 36 23 00015488 secp256k1_nonce_function_rfc6979
56 37 24 0000DF10 secp256k1_scratch_space_create
57 38 25 0000DF80 secp256k1_scratch_space_destroy
58 39 26 00012380 secp256k1_tagged_sha256
59
60 Summary
61
62 1000 .CRT
63 1000 .bss
64 1000 .data
65 3000 .debug_abbrev
66 1000 .debug_aranges
67 3000 .debug_frame
68 4A000 .debug_info
69 E000 .debug_line
70 29000 .debug_loc
71 9000 .debug_ranges
72 1000 .debug_str
73 1000 .edata
74 1000 .idata
75 1000 .pdata
76 111000 .rdata
77 1000 .reloc
78 13000 .text
79 1000 .tls
80 1000 .xdata
Builders cross-compiling for Windows (including Core) will no-longer see:
0libtool: 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.
FWIW, with CPPFLAGS='-D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC' linking the bench.exe fails now:
0 CCLD bench.exe
1libtool: error: Could not determine the host path corresponding to
2libtool: error: '/home/hebasto/GitHub/secp256k1/.libs'
3libtool: error: Continuing, but uninstalled executables may not work.
4libtool: error: Could not determine the host path corresponding to
5libtool: error: '/home/hebasto/GitHub/secp256k1/.libs:/usr/local/lib:/usr/local/bin'
6libtool: 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.