Newest at the top
2025-09-07 02:11:02 +0200 | trickard_ | (~trickard@cpe-53-98-47-163.wireline.com.au) |
2025-09-07 02:10:48 +0200 | trickard | (~trickard@cpe-53-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
2025-09-07 02:10:09 +0200 | Guest62 | (~Guest62@c-73-217-79-154.hsd1.co.comcast.net) |
2025-09-07 02:06:53 +0200 | potato44 | (uid421314@id-421314.lymington.irccloud.com) potato44 |
2025-09-07 02:01:44 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
2025-09-07 02:00:48 +0200 | sprotte24 | (~sprotte24@p200300d16f1ae200cce55c66184a5d60.dip0.t-ipconnect.de) (Quit: Leaving) |
2025-09-07 02:00:14 +0200 | <slondr> | yeah that's definitely not the case here. I'm in a blank directory with one .hs file |
2025-09-07 02:00:06 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
2025-09-07 01:59:54 +0200 | <geekosaur> | that said, nix wouldn't insert a ghc into your path unless you're in a directorry with a shell.nix and something knows enough about nix to see that file and load the derivations it specifies |
2025-09-07 01:57:44 +0200 | <geekosaur> | shells cache paths, but something run in a subshell or by a program you run from that shell won;t see the cache and will find the nix one first in that case |
2025-09-07 01:57:07 +0200 | <slondr> | though 'echo $PATH' sure does report that the /nix bin directories are above the ghcup bin directories, hmm |
2025-09-07 01:56:44 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-07 01:56:16 +0200 | <slondr> | 'which ghc' reports: $HOME/.ghcup/bin/ghc |
2025-09-07 01:55:56 +0200 | <geekosaur> | the ghc from ghcup won't know about nix |
2025-09-07 01:55:42 +0200 | <geekosaur> | make sure nix isn't substituting its own ghc for the one you intended to use |
2025-09-07 01:54:47 +0200 | <slondr> | I'm not sure why it does |
2025-09-07 01:54:42 +0200 | <slondr> | I don't want ghc to reference anything nix-related at all |
2025-09-07 01:53:43 +0200 | <geekosaur> | nix really wants to be hermetic, but that can break things pretty thoroughly when it comes to stuff like glibc |
2025-09-07 01:52:52 +0200 | <geekosaur> | https://github.com/NixOS/patchelf |
2025-09-07 01:52:25 +0200 | <slondr> | which seems almost certainly wrong, I'd want ghc to reference the system glibc not some random nix derivation glibc |
2025-09-07 01:52:00 +0200 | <slondr> | wait wait wait wait. the glibc error seems to be referencing a glibc version installed by nix |
2025-09-07 01:51:40 +0200 | <geekosaur> | okay, if Arch changed their glibc recently then ghcup's release builds probably need to be adjusted |
2025-09-07 01:50:42 +0200 | fp | (~Thunderbi@89-27-10-140.bb.dnainternet.fi) (Ping timeout: 260 seconds) |
2025-09-07 01:48:07 +0200 | <slondr> | I ran GHCup via the curl | bash command on the website |
2025-09-07 01:47:54 +0200 | <slondr> | ah you see, i have already done that. my ghc is from GHCup. |
2025-09-07 01:47:33 +0200 | <geekosaur> | this might be a question for maerwald, but the answer may again be "give up on the Arch ghc install" because it just causes too many problems for Haskell maintainers |
2025-09-07 01:46:17 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
2025-09-07 01:45:43 +0200 | <slondr> | yeah I just have the normal default Arch Linux glibc |
2025-09-07 01:45:30 +0200 | <geekosaur> | also I have 2.41 but it's Ubuntu's build |
2025-09-07 01:45:18 +0200 | <geekosaur> | okay, so that's not it (same here) |
2025-09-07 01:44:35 +0200 | <slondr> | libc ABIs: UNIQUE IFUNC ABSOLUTE |
2025-09-07 01:44:21 +0200 | ljdarj1 | ljdarj |
2025-09-07 01:44:21 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 250 seconds) |
2025-09-07 01:44:18 +0200 | hiredman | (~hiredman@frontier1.downey.family) hiredman |
2025-09-07 01:44:12 +0200 | <geekosaur> | if you can find libc.so.6, can you run it as if it were a program and if so what does it say for "libc ABIs"? |
2025-09-07 01:43:17 +0200 | hiredman | (~hiredman@frontier1.downey.family) (Remote host closed the connection) |
2025-09-07 01:42:13 +0200 | <geekosaur> | the question is whether or how your glibc supports linux's native posix threads library (the "nptl" in that symbol) |
2025-09-07 01:41:46 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-07 01:41:05 +0200 | <slondr> | I'm on glibc 2.42 should I expect hls to support that? |
2025-09-07 01:40:55 +0200 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
2025-09-07 01:39:16 +0200 | <geekosaur> | the undefined symbol one sounds like much more of a problem |
2025-09-07 01:39:01 +0200 | <geekosaur> | right, you need an HLS binary for each ghc version because the ghc-api it uses must match |
2025-09-07 01:36:48 +0200 | <slondr> | I also see: libc.so.6: undefined symbol: __nptl_change_stack_perm, version GLIBC_PRIVATE |
2025-09-07 01:36:16 +0200 | <slondr> | emacs lsp reports: ghc 9.6.7, cabal 3.12.1.0, stack 3.3.1 |
2025-09-07 01:33:38 +0200 | <slondr> | It looks like I also have haskell-language-server-9.6.7 |
2025-09-07 01:33:02 +0200 | <slondr> | my hls binary is named "haskell-language-server-9.4.8" |
2025-09-07 01:32:51 +0200 | <slondr> | oh! that's a clue |
2025-09-07 01:32:18 +0200 | <geekosaur> | also that sounds like an out of date ghcup, or at least ghcup metadata; current metadata has 9.6.7 as recommended |
2025-09-07 01:31:30 +0200 | <geekosaur> | HLS versions don't go that high |
2025-09-07 01:31:22 +0200 | <geekosaur> | you mean ghc version? |