Subject: Re: [core-updates] GHC 8.6.5 build failure

From: Marius Bakke <[email-masked]>
Date: Mon, 23 Mar 2020 23:45:51 +0100

Marius Bakke <[email-masked]> writes:

> Hello,
>
> On the 'core-updates' branch, GHC 8.6.5 consistently fails a single
> test:
>
> =====> T13702(normal) 1219 of 6523 [0, 0, 0]
> cd "./dynlibs/T13702.run" && $MAKE --no-print-directory -s T13702  
> Wrong exit code for T13702()(expected 0 , actual 2 )
> Stdout ( T13702 ):
> hello world
> Stderr ( T13702 ):
> T13702a: user error (dlopen: ./T13702: cannot dynamically load position-independent executable)
> make[2]: *** [Makefile:60: T13702] Error 1
> *** unexpected failure for T13702(normal)
>
> Here is the test in question:
>
> https://gitlab.haskell.org/ghc/ghc/blob/master/testsuite/tests/dynlibs/T13702.hs
>
> Initially I thought this has to do with the LibFFI 3.3 upgrade, but
> reverting commit 5f1000d5d4cc4dfc9a1fe220457c17ad011d9e33 did not make a
> difference.

This turned out to be because of a change in glibc 2.30, where dlopening
a position-independent executable has been disallowed:

https://sourceware.org/bugzilla/show_bug.cgi?id=24323

Test T13702 verifies that creating position-independent executables
work, by running and dlopening one.  Commit
2e9c43aa9adac2bd6bcf92373d1cf9f322afa5a3 attempted to disable test
T13702a which dlopens it, but the build still failed: 

cd "./driver/recomp017/recomp017.run" && $MAKE -s --no-print-directory recomp017  --- ./dynlibs/T13702.run/T13702.stdout.normalised     2020-03-23 19:45:14.063130812 +0000
+++ ./dynlibs/T13702.run/T13702.run.stdout.normalised   2020-03-23 19:45:14.063130812 +0000
@@ -1,2 +1 @@
 hello world
-hello world again

Sorry for the incomplete fix, I must have watched the wrong terminal
window when coming back to check on the build progress.  This is the
part that now fails:

{-# LANGUAGE ForeignFunctionInterface #-}
main :: IO ()
main = putStrLn "hello world"
foreign export ccall "hello" hello :: IO ()
hello :: IO ()
hello = putStrLn "hello world again"

Which looks like the same problem just in a different part of the test.
I'll try to fix it properly tomorrow and also notify upstream.