Hi,
The build for ghc-cryptonite failed in the mass rebuild [1] and a later rebuild by me [2], but only on s390x. The failure appears to be LTO related. This doesn't appear to affect many other Haskell packages. (I've found one seemingly-related failure in ghc-haskell-src-exts [3].) Since it's Haskell, I'm using the standard macros that should pass consistent flags, etc., so I'm not sure what more information I can provide.
What happens is that ld.gold warns about mixed LTO/non-LTO:
[ 1 of 131] Compiling Crypto.Cipher.DES.Primitive ( Crypto/Cipher/DES/Primitive.hs, dist/build/Crypto/Cipher/DES/Primitive.p_o ) /usr/bin/ld.gold: warning: incremental linking of LTO and non-LTO objects; using -flinker-output=nolto-rel which will bypass whole program optimization
and then errors out because of many LTO mismatches like:
/tmp/ghc794663_0/ghc_19.c:11:19: error: warning: type of ‘cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc’ does not match original declaration [-Wlto-type-mismatch] 11 | extern CostCentre cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]; | ^ | 11 | extern CostCentre cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]; | ^ /tmp/ghc794663_0/ghc_18.hc:44:9: error: note: type ‘StgWord’ should match type ‘struct CostCentre’ 44 | StgWord cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))= { | ^ | 44 | StgWord cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))= { | ^ /tmp/ghc794663_0/ghc_18.hc:44:9: error: note: ‘cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc’ was previously declared here | 44 | StgWord cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))= { | ^ /tmp/ghc794663_0/ghc_18.hc:44:9: error: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used | 44 | StgWord cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))= { | ^
followed by inlining failures:
/usr/include/bits/string_fortified.h: In function ‘fill_segment’: /usr/include/bits/string_fortified.h:59:1: error: error: inlining failed in call to ‘always_inline’ ‘memset’: function body can be overwritten at link time 59 | __NTH (memset (void *__dest, int __ch, size_t __len)) | ^ | 59 | __NTH (memset (void *__dest, int __ch, size_t __len)) | ^
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=47957210 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=48408236 [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=48322376
Hi Elliot, thanks for the heads up:
On Mon, Aug 3, 2020 at 8:12 AM Elliott Sales de Andrade < quantum.analyst@gmail.com> wrote:
The build for ghc-cryptonite failed in the mass rebuild [1] and a later rebuild by me [2], but only on s390x. The failure appears to be LTO related. This doesn't appear to affect many other Haskell packages. (I've found one seemingly-related failure in ghc-haskell-src-exts [3].) Since it's Haskell, I'm using the standard macros that should pass consistent flags, etc., so I'm not sure what more information I can provide.
What happens is that ld.gold warns about mixed LTO/non-LTO:
Yeah this seems to be affecting profiling libraries (ghc-*-prof.s390x).
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=48408236
I opened https://bugzilla.redhat.com/show_bug.cgi?id=1863601 using the output from this build.
For now I am going to workaround this by disabling LTO for s390x Haskell packages in ghc-rpm-macros. I think when we move to ghc-8.10 for F34 we can hopefully switch s390x to llvm10 which should make this problem go away.
Thanks, Jens