Enable dynamic linking in stack builds

[pepeiborra]

CircleCI is running OOM during linking (except in the 9.0.1 build for some reason).

I don't know what has changed, but perhaps we can simply avoid linking at all?

I don't use stack so this change is untested - let's see if it helps.

[pepeiborra]

This trick fixed all of the stack descriptors except for 8.10.2 and 8.8.3 which failed with missing symbols:

haskell-language-server    > Linking .stack-work/dist/x86_64-linux/Cabal-3.2.0.0/build/haskell-language-server/haskell-language-server ...
haskell-language-server    > /root/build/.stack-work/install/x86_64-linux/f3f49bf4ac032c7619cfe1025b8b145af2cf9e1441fbd546d7b35194c65ee152/8.10.2/lib/x86_64-linux-ghc-8.10.2/libHShaskell-language-server-1.2.0.0-8qfPiwzpJpQLEeoSgZzfcY-ghc8.10.2.so: error: undefined reference to 'ghcidezm1zi4zi0zi3zm3vlArMAjZZZZA21j2DgvbvhY_DevelopmentziIDEziTypesziOptions_defaultIdeOptions102_closure'
haskell-language-server    > /root/build/.stack-work/install/x86_64-linux/f3f49bf4ac032c7619cfe1025b8b145af2cf9e1441fbd546d7b35194c65ee152/8.10.2/lib/x86_64-linux-ghc-8.10.2/libHShaskell-language-server-1.2.0.0-8qfPiwzpJpQLEeoSgZzfcY-ghc8.10.2.so: error: undefined reference to 'ghcidezm1zi4zi0zi3zm3vlArMAjZZZZA21j2DgvbvhY_DevelopmentziIDEziTypesziOptions_defaultIdeOptions100_closure'
haskell-language-server    > collect2: error: ld returned 1 exit status
haskell-language-server    > `gcc' failed in phase `Linker'. (Exit code: 1)

haskell-language-server    > Linking .stack-work/dist/x86_64-linux/Cabal-3.0.1.0/build/haskell-language-server/haskell-language-server ...
haskell-language-server    > /root/build/.stack-work/install/x86_64-linux/89919912141e757f87cefaf5da67a39a1a21d1d491c15dc382ee9d690a5aa718/8.8.3/lib/x86_64-linux-ghc-8.8.3/libHShaskell-language-server-1.2.0.0-E2I96ASAWC068YL6trCZ0h-ghc8.8.3.so: error: undefined reference to 'ghcidezm1zi4zi0zi3zm49GiRv7Rp7Q9ibeyBQRIfY_DevelopmentziIDEziTypesziOptions_defaultIdeOptions100_closure'
haskell-language-server    > /root/build/.stack-work/install/x86_64-linux/89919912141e757f87cefaf5da67a39a1a21d1d491c15dc382ee9d690a5aa718/8.8.3/lib/x86_64-linux-ghc-8.8.3/libHShaskell-language-server-1.2.0.0-E2I96ASAWC068YL6trCZ0h-ghc8.8.3.so: error: undefined reference to 'ghcidezm1zi4zi0zi3zm49GiRv7Rp7Q9ibeyBQRIfY_DevelopmentziIDEziTypesziOptions_defaultIdeOptions102_closure'
haskell-language-server    > collect2: error: ld returned 1 exit status
haskell-language-server    > `gcc' failed in phase `Linker'. (Exit code: 1)

[pepeiborra]

These missing symbols errors are probably due to reusing previous compile artifacts. Does anyone know how to wipe out the circle CI cache?

[jneira]

These missing symbols errors are probably due to reusing previous compile artifacts. Does anyone know how to wipe out the circle CI cache?

Prefixing cache keys with v2- or dynamic- should do the trick.

Anyways this should be something temporary, no?, until we discover why static linking has started to throw OOM. Theoretically users building with stack could be affected.

[pepeiborra]

These missing symbols errors are probably due to reusing previous compile artifacts. Does anyone know how to wipe out the circle CI cache?

Prefixing cache keys with v2- or dynamic- should do the trick.

Anyways this should be something temporary, no?, until we discover why static linking has started to throw OOM. Theoretically users building with stack could be affected.

No, it's not temporary. Users building with stack are better off using dynamic builds.

[jneira]

No, it's not temporary. Users building with stack are better off using dynamic builds.

Mmm maybe (woud like to know the reasons though) but the default configuration builds statically, no? so users not changing it on purpose will use it

[jneira]

lgtm, thanks for unblocking ci

[pepeiborra]

No, it's not temporary. Users building with stack are better off using dynamic builds.

Mmm maybe (woud like to know the reasons though) but the default configuration builds statically, no? so users not changing it on purpose will use it

We have known for a while that dynamic builds are preferable, there's a long list of user issues where the resolution is always: use a dynamic build. The most recent one is #2000

[jneira]

Yeah, but afaik not all linux envs needs the dynamic build. So maybe force the dynamic linking could cause problems there. But, well, let's see if some issue is opened by that.

[pepeiborra]

What makes you think that? All Linux and Mac environments would be better off with a dynamic build. I am only unsure about Windows.

[jneira]

Mmm maybe i am overlooking it, sorry. I think dynamic build in windows is ignored and is static anyways (https://gitlab.haskell.org/ghc/ghc/-/wikis/windows-dynamic-linking)