Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable dynamic linking in stack builds #2031

Merged
merged 2 commits into from
Jul 22, 2021
Merged

Enable dynamic linking in stack builds #2031

merged 2 commits into from
Jul 22, 2021

Conversation

pepeiborra
Copy link
Collaborator

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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

@jneira
Copy link
Member

jneira commented Jul 22, 2021

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
Copy link
Collaborator Author

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
Copy link
Member

jneira commented Jul 22, 2021

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

Copy link
Member

@jneira jneira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, thanks for unblocking ci

@pepeiborra
Copy link
Collaborator Author

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

@pepeiborra pepeiborra merged commit 45fdb25 into master Jul 22, 2021
@pepeiborra pepeiborra deleted the stack-dynamic branch July 22, 2021 15:26
@jneira
Copy link
Member

jneira commented Jul 23, 2021

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
Copy link
Collaborator Author

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
Copy link
Member

jneira commented Jul 23, 2021

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants