On Mon, 12 Aug 2019, Richard Biener wrote:
On Sun, 11 Aug 2019, Hans-Peter Jansen wrote:
Am Dienstag, 23. April 2019, 14:02:20 CEST schrieb Martin Liška:
Hi.
We as toolchain team are working on enablement of LTO in Factory:
Since that switch, veracrypt doesn't build anymore due to a lto-wrapper error:
https://build.opensuse.org/package/show/security/veracrypt
Any idea anybody?
[ 246s] ../Crypto/Whirlpool.c:105:45: error: 'Whirlpool_C' causes a section type conflict with 'SHA256_K' [ 246s] 105 | CRYPTOPP_ALIGN_DATA(16) static const uint64 Whirlpool_C[8*256+R] CRYPTOPP_SECTION_ALIGN16 = { [ 246s] | ^ [ 246s] ../Crypto/Sha2.c:321:34: note: 'SHA256_K' was declared here [ 246s] 321 | CRYPTOPP_ALIGN_DATA(16) uint_32t SHA256_K[64] CRYPTOPP_SECTION_ALIGN16 = { [ 246s] | ^
so the question is how CRYPTOPP_SECTION_ALIGN16 / CRYPTOPP_ALIGN_DATA are defined for the respective TUs. One appearant difference is that Whirlpool_C is declared 'const' while SHA256_K is not so if the section is named that might be the issue.
OK, so google works and spits out
#ifndef CRYPTOPP_SECTION_ALIGN16
#if defined(__GNUC__) && !defined(__APPLE__)
// the alignment attribute doesn't seem to work without
this section attribute when -fdata-sections is turned on
#define CRYPTOPP_SECTION_ALIGN16 __attribute__((section
("CryptoPP_Align16")))
so indeed a named section. Make SHA256_K 'const' and see if that works
(or Whirlpool_C non-const, might be more "mismatches" exist).
Richard.
--
Richard Biener