Revert dynamically linking ghc.

Authored by DavidEichmann on Dec 10 2018, 10:55 AM.



Building a dynamically linked ghc is broken do to incorrectly building
and installing libffi. This disables building a dynamically linked ghc
and ghc-iserv-dyn while keeping most of the code in the relevant
commits: 79d5427e1 and 89fa34ecd

Test Plan

Ensure build environment does NOT have a system libffi installed (you may want to use a nix environment).
Then hadrian/ -c --flavour=default.

Diff Detail

rGHC Glasgow Haskell Compiler
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
DavidEichmann created this revision.Dec 10 2018, 10:55 AM
DavidEichmann updated the Trac tickets for this revision.

I've tested locally using a nix environment where the Hadrian default build fails on master. With this patch I successfully built and ran tests for flavours: default, perf, quick, and quickest.

alpmestan accepted this revision.Dec 10 2018, 12:51 PM

This will do for fixing the build and will give us time to fix this all properly, including making use of platformSupportsSharedLibs and dynamicGhcPrograms in requiresDynamic.

This revision is now accepted and ready to land.Dec 10 2018, 12:51 PM

Do we know what the actual issue is here? Are we certain that D5427 doesn't fix it?

The build failure in question is failing to find libffi when building the default flavour on x86_64 with no system wide libffi installed. The command that fails is when linking the ghc binary. The make build system links the ghc binary with -lffi. On that grounds I would say that D5427 will not solve this issue that this patch does.

Do we know what the actual issue is here?

Yes: Hadrian doesn't build/install libffi correctly and ghc and cabal disagree on the name of the libffi .so file (e.g. cabal expects while ghc expects

This revision was automatically updated to reflect the committed changes.