Error in emacs: can't load .so/.DLL for libm.so.6 due to GLIBC_2.29 #32
Comments
|
Also after that error sometimes this other error also shows up: I believe it is related to the first error failing on finding the appropriate glibc libraries. |
|
Have you tried clearing |
|
I switched to nix-built hie from a system with glibc 2.29, with nix using 2.27. The libs built into |
|
I think I'm also running into this. Removing (source SystemVim 8.1 |
|
@andys8 in |
|
|
I tried to use nix, but not use the |
|
your stack linked against |
Issues with `all-hies` on arch <infinisil/all-hies#32 (comment)>
|
Hmm. I need to build $ which -a stack ghc cabal
/home/andreas/.nix-profile/bin/stack
/home/andreas/.nix-profile/bin/ghc
/home/andreas/.nix-profile/bin/cabal |
|
well, something in the toolchain has got to be linking to the operating system's glibc. is there another stack or ghc in the system? maybe try removing that from the path, also check |
|
There is (currently) no other $ ldd (which stack)
linux-vdso.so.1 (0x00007ffdef9fe000)
libm.so.6 => /nix/store/kksyrix1bpklvgkmvngcv0q9nh8hn2fl-glibc-2.27/lib/libm.so.6 (0x00007f3156cdd000)
libsqlite3.so.0 => /nix/store/cx2a04bg8339r039wqx6wqjblxwjbwg1-sqlite-3.28.0/lib/libsqlite3.so.0 (0x00007f3156bc5000)
libpthread.so.0 => /nix/store/kksyrix1bpklvgkmvngcv0q9nh8hn2fl-glibc-2.27/lib/libpthread.so.0 (0x00007f3156ba4000)
libz.so.1 => /nix/store/f8zs7mknva4rdx7zxr6j54y0igh3pras-zlib-1.2.11/lib/libz.so.1 (0x00007f3156b85000)
librt.so.1 => /nix/store/kksyrix1bpklvgkmvngcv0q9nh8hn2fl-glibc-2.27/lib/librt.so.1 (0x00007f3156b7b000)
libutil.so.1 => /nix/store/kksyrix1bpklvgkmvngcv0q9nh8hn2fl-glibc-2.27/lib/libutil.so.1 (0x00007f3156b74000)
libdl.so.2 => /nix/store/kksyrix1bpklvgkmvngcv0q9nh8hn2fl-glibc-2.27/lib/libdl.so.2 (0x00007f3156b6f000)
libgmp.so.10 => /nix/store/vqc2zncb0f1b945dq7j2pcyygfxmcf3v-gmp-6.1.2/lib/libgmp.so.10 (0x00007f3156ad9000)
libffi.so.6 => /nix/store/i5b8dwcyh4kjmsp7ggffn5frq1ib5dd3-libffi-3.2.1/lib/libffi.so.6 (0x00007f3156acd000)
libc.so.6 => /nix/store/kksyrix1bpklvgkmvngcv0q9nh8hn2fl-glibc-2.27/lib/libc.so.6 (0x00007f3156917000)
/nix/store/kksyrix1bpklvgkmvngcv0q9nh8hn2fl-glibc-2.27/lib/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f3156e75000)But when running I'm pretty sure I'm doing at least something wrong or there is cached data not being deleted. I'll stick with installing |
|
just to be safe, does your global |
|
I have bumped into this because of the glibc update in nixpkgs. hie from all-hies doesn't work when ghc is sourced from NixOS/nixpkgs@3846896084f but it does work when ghc is sourced from the parent commit NixOS/nixpkgs@fa744553290 |
|
I'm experiencing this with a cabal project that uses ghc-8.6.5. |
|
@poscat0x04 FWIW I've switched to ghc882 which seems to be running without issue . |
|
Yeah switching to ghc882 worked but a lot of binary caches were missing. |
|
This issue also affects |
|
I recently talked with @domenkozar regarding this. It seems that the glibc version for HIE and the one for the GHC in your environment have to match for it to work. The same goes for ghcide. Looking at the glibc versions used for stable all-hies, they're
So for now the best workaround should be to make sure the GHC you have uses the same glibc version. You should be able to check your GHC's glibc version with or if |
|
Thanks for the elaboration. Would it be possible to script this check into the mix expression itself, so it'll deny installation and say "your system would only work with |
|
I have to do some rewriting for switching to 1.2, see #52. This might enable a better way to deal with this. |
|
I am trying to do some haskell work and would love to get HIE in but I get this error (ghcide works fine but it lacks completion). due to the lockdown, I am at home with an 8 year old laptop and ~7Gb of free disk space, hence my question, I would like to make sure before trying anything. |
|
@teto Yeah I think that would work if you need ghc865 for glibc 2.30. Note that if you do this, you'll also have to add the correct hash for that nixpkgs rev in https://github.com/Infinisil/all-hies/tree/master/generated/stable/nixpkgsHashes. |
|
I have the same issue. As I understood, the solution for it - to not use cachix? |
|
you should run a ghc using the same glibc as hie. Each hie version uses a specific nixpkgs so:
|
|
@teto could you help me, I'm using this derivation in my shell.nix As far as I see, latest all-hies is used there So I have to use other nixpkgs commit? If you solved this issue, could you please share nixpkgs commit where everything is working? |
- workaround for infinisil#32
|
I just bumped hie-865 for ghc865 to build against glibc-2.30 by building against a recent nixpkgs commit from release-20.03. @infinisil How do you usually compute the sha256sum of a nixpkgs revision? This probably requires removing/ ignoring the .git directory. I just took the "let-it-fail" approach, but maybe there's a better way. |
- workaround for infinisil#32
|
@schmittlauch Usually that's done by the update script (see https://github.com/infinisil/all-hies#updating-this-repository, the calculation is done here), though the whole script takes quiet a while to run, probably not worth for just such a simple change. |
|
Btw, I found alternative workaround - just needed to downgrade my nixpkgs to |
|
@tkachuk-labs Which nixpkgs where? |
|
@infinisil So what do you think about rebuilding all relevant versions against a recent commit from release-20.03, once that is out of beta? |
I think the requirement is even stricter. Regardless of what GHC is installed in my profile / visible through PATH, I suspect the stack nix tooling will install "the system GHC" based on your default Case in point, I have installed into my profile the exact ghc-8.6.5 that comes from hie: and you can see that ghc uses glibc 2.27:
nix:
enable: true
packages: [zlib.dev, zlib.out]The zlib is thanks to commercialhaskell/stack#2130 (comment), without which stack build will fail to build zlib. However, hie still breaks like so: As you can see, for some reason it's still trying to use the |
|
@dansanduleac Check out https://docs.haskellstack.org/en/stable/nix_integration/#package-sources, which should allow you to set e.g. nix:
path: [nixpkgs=https://github.com/NixOS/nixpkgs/tarball/650a295621b27c4ebe0fa64a63fd25323e64deb3]So Stack takes the GHC version from there instead of the default |
|
@infinisil, I've upgraded from HIE 1.1 to HIE 1.4 using the haskell.nix branch. I'm using Stack on Nix and I can't find the appropriate commit to pin my GHC 8.6.5 to (as per your previous comment). Using
I can't find https://github.com/Infinisil/all-hies/blob/master/nixpkgsForGhc/ghc865 on the |
|
@steshaw The haskell.nix branch always uses a nixpkgs with glibc 2.30, so any recent nixpkgs will work (e.g. 20.03 or unstable) |
|
Thanks, @infinisil. I used |
|
This should now be fixed with the project revamp in #64, which forces a project-local Nix environment, in which the glibc version can be matched against the one GHC uses |
After some issues with the non-nix build I decided to move to the nix build. When starting a new stack project I am able to use hie perfectly fine as seen here:
But I have a specific project in which I can't make this work and it is related to the nix build. When I open the project I get these messages:
As seen in the error message,
libHSerfrequiresGLIBC_2.29and thelibmthat is being retrieved is the one inside the nix store which isglibc-2.27.I'm using
cabal-install-2.4.1.0because there seems to be some issues withcabal-install-3.0.0.0.The text was updated successfully, but these errors were encountered: