GHC >= 9.6 TemplateHaskell doesn't work in pkgsStatic #275304

bgamari · 2023-12-19T00:37:00Z

Describe the bug

Haskell packages in nixpkgs.pkgsStatic.haskell.packages.ghc98 are unable to be built.

Steps To Reproduce

Steps to reproduce the behavior:

nix build nixpkgs#legacyPackages.x86_64-linux.pkgsStatic.haskell.packages.ghc98.Diff

Expected behavior

Diff is built, linking against musl.

Observed behavior

nix-repl> :b legacyPackages.x86_64-linux.pkgsStatic.haskell.packages.ghc98.Diff                                                                                                                                               error: build of '/nix/store/ickzn6az4asiwrh1wq20blm0dvcr5w17-Diff-static-x86_64-unknown-linux-musl-0.4.1.drv' on 'ssh://ben@maurer.local' failed: builder for '/nix/store/ickzn6az4asiwrh1wq20blm0dvcr5w17-Diff-static-x86_64-unknown-linux-musl-0.4.1.drv' failed with exit code 1;
       last 10 log lines:
       >    | ^^^^^^^^^^^^^^^^^^^^^^^^^^
       >
       > src/Data/Algorithm/Diff.hs:29:1: error: [GHC-47808]
       >     Failed to load dynamic interface file for Data.Array:
       >       Exception when reading interface file  /nix/store/zb7g1q1vza1x0fmb8qk8cv9y23b9w81g-x86_64-unknown-linux-musl-ghc-9.8.1/lib/x86_64-unknown-linux-musl-ghc-9.8.1/lib/../lib/x86_64-linux-ghc-9.8.1/array-0.5.6.0-inplace/Data/Array.dyn_hi
       >         /nix/store/zb7g1q1vza1x0fmb8qk8cv9y23b9w81g-x86_64-unknown-linux-musl-ghc-9.8.1/lib/x86_64-unknown-linux-musl-ghc-9.8.1/lib/../lib/x86_64-linux-ghc-9.8.1/array-0.5.6.0-inplace/Data/Array.dyn_hi: withBinaryFile: does not exist (No such file or directory)
       >    |
       > 29 | import Data.Array (listArray, (!))
       >    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       > load' failed
       For full logs, run 'nix log /nix/store/ickzn6az4asiwrh1wq20blm0dvcr5w17-Diff-static-x86_64-unknown-linux-musl-0.4.1.drv'.
error: builder for '/nix/store/ickzn6az4asiwrh1wq20blm0dvcr5w17-Diff-static-x86_64-unknown-linux-musl-0.4.1.drv' failed with exit code 1;
       last 10 log lines:
       >    | ^^^^^^^^^^^^^^^^^^^^^^^^^^
       >
       > src/Data/Algorithm/Diff.hs:29:1: error: [GHC-47808]
       >     Failed to load dynamic interface file for Data.Array:
       >       Exception when reading interface file  /nix/store/zb7g1q1vza1x0fmb8qk8cv9y23b9w81g-x86_64-unknown-linux-musl-ghc-9.8.1/lib/x86_64-unknown-linux-musl-ghc-9.8.1/lib/../lib/x86_64-linux-ghc-9.8.1/array-0.5.6.0-inplace/Data/Array.dyn_hi
       >         /nix/store/zb7g1q1vza1x0fmb8qk8cv9y23b9w81g-x86_64-unknown-linux-musl-ghc-9.8.1/lib/x86_64-unknown-linux-musl-ghc-9.8.1/lib/../lib/x86_64-linux-ghc-9.8.1/array-0.5.6.0-inplace/Data/Array.dyn_hi: withBinaryFile: does not exist (No such file or directory)
       >    |
       > 29 | import Data.Array (listArray, (!))
       >    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       > load' failed
       For full logs, run 'nix log /nix/store/ickzn6az4asiwrh1wq20blm0dvcr5w17-Diff-static-x86_64-unknown-linux-musl-0.4.1.drv'.

Additional context

The problem here appears to manifest during building of Haddock documentation. For instance,

$ nix repl
nix-repl> :lf nixpkgs#
nix-repl> :b legacyPackages.x86_64-linux.haskell.lib.dontHaddock (legacyPackages.x86_64-linux.pkgsStatic.haskell.packages.ghc98.Diff)

This derivation produced the following outputs:
  out -> /nix/store/5096rq1664b9qq2f2g9ih0sv6is48d8z-Diff-static-x86_64-unknown-linux-musl-0.4.1

Notify maintainers

@nh2

The text was updated successfully, but these errors were encountered:

bgamari · 2023-12-19T00:38:31Z

My suspicion here is that this is either a Cabal or Haddock bug, although I'm not yet sure which.

angerman · 2023-12-19T09:26:53Z

Of note: something assumes the existence of dynamic files, while there are none. Not quite sure why GHC would try to load dynamic files.
Trying to read

/nix/store/s13v3xsi60z627ic821fm70mlw43a3za-x86_64-unknown-linux-musl-ghc-9.8.1/lib/x86_64-unknown-linux-musl-ghc-9.8.1/lib/../lib/x86_64-linux-ghc-9.8.1/array-0.5.6.0-inplace/Data/Array.dyn_hi

however

/nix/store/s13v3xsi60z627ic821fm70mlw43a3za-x86_64-unknown-linux-musl-ghc-9.8.1/lib/x86_64-unknown-linux-musl-ghc-9.8.1/lib/../lib/x86_64-linux-ghc-9.8.1/array-0.5.6.0-inplace/Data
total 27K
dr-xr-xr-x 3 root root    5 Jan  1  1970 .
dr-xr-xr-x 3 root root    7 Jan  1  1970 ..
dr-xr-xr-x 6 root root   22 Jan  1  1970 Array
-r--r--r-- 2 root root 2.9K Jan  1  1970 Array.hi
-r--r--r-- 2 root root 2.9K Jan  1  1970 Array.p_hi

Maybe someone has an idea where the dyn_hi load comes from.

rnhmjoj · 2023-12-19T09:41:37Z

ping: @NixOS/static

sternenseemann · 2023-12-19T11:05:50Z

Good to know that the hadrian regression from #208959 has been fixed, so we can at least build GHC now.

sternenseemann · 2023-12-19T12:03:58Z

My diagnosis is the following:

Hadrian silently disables building the haddock executable, presumably because docs are disabled (so maybe building core lib docs and building the haddock executable is still the same flag?)
This is not known to haskellPackages.mkDerivation, since I dropped the enableHaddockProgram flag when I ported the GHC expression to Hadrian, presumably either because cross was completely broken initially or I assumed it got fixed.
When Cabal gets told to build docs, it uses the only haddock in scope, the one from the build->build compiler which doesn't work of course.

I can fix that by just disabling haddock in the same way as we do for GHC < 9.6. I'll try doing that later.

@bgamari @angerman The question is of course, and you can answer that better than me, has anything changed w.r.t. hadddock and cross with Hadrian?

bgamari · 2023-12-19T16:12:08Z

Thanks @sternenseemann! Your hypothesis does sound plausible.

Recently we did rework Haddock to take documentation from Haskell interface (.hi) files. I can't help but wonder whether this logic may be culpable: https://gitlab.haskell.org/ghc/haddock/-/blob/b0b0e0366457c9aefebcc94df74e5de4d00e17b7/haddock-api/src/Haddock.hs#L170. This was apparently introduced due to haskell/haddock#256.

sternenseemann · 2023-12-19T17:25:36Z

Seems plausible. I'm personally not too fussed that this change means that haddock is not “retargetable”, i.e. you always need to use the precise haddock bundled with the GHC you are using to compile the documented code. In fact, we probably should explicitly tell Cabal which haddock to use, so this kind of issue doesn't happen or is easier to diagnose.

I'll need to investigate, though, under which circumstances we can build haddock with hadrian now.

sternenseemann · 2023-12-19T23:35:17Z

The problems seems to be that the haddock package is only built using the stage1 compiler (so as part of stage2) which we necessarily never reach in the case of cross compilation. Presumably we can work around this in UserSettings somehow (although IME you are quite limited if your solution is to be maintainable), but I feel like this is a genuine gap and there ought to be a better way to build a cross-compiler with hadrian…

angerman · 2023-12-20T09:38:41Z

I've just skimmed the code, but why do we do this:

  -- Inject dynamic-too into ghc options if the ghc we are using was built with
  -- dynamic linking
  flags'' <- ghc flags $ do
        df <- getDynFlags
        case lookup "GHC Dynamic" (compilerInfo df) of
          Just "YES" -> return $ Flag_OptGhc "-dynamic-too" : flags
          _ -> return flags

what's the rational for adding -dynamic-too here? I can somewhat extract the rational from haskell/haddock#256, but the comment above this is rather poor. Also it does not provide any way to pass to haddock to prevent this automagic.

I guess the proper thing here is to just disable haddocks for cross, and rely on native compilers haddocks.

sternenseemann · 2023-12-20T09:47:34Z

I guess the proper thing here is to just disable haddocks for cross, and rely on native compilers haddocks.

Do you mean the native compiler's haddock executable or re-using the documentation built natively? The former currently happens (unintentionally) and seems to be the source of the problem…

In this situation, haddock would not be built by hadrian, as there is no stage0:exe:haddock target by default. (We should eventually try adding one.) If haddock is enabled and the build->host haddock missing, Cabal tries using the build->build haddock which may fail to load the documentation from the interface files produced by the build->host GHC (e.g. due to a mismatch between dynamic and static linking). Add regression tests to haskell-updates jobset. Resolves NixOS#275304.

angerman · 2023-12-20T11:13:51Z

@sternenseemann

re-using the documentation built natively

This :D

domenkozar · 2024-01-24T16:06:13Z

It's still broken: https://github.com/domenkozar/nixpkgs-static-repo

domenkozar · 2024-01-24T16:16:24Z

Even easier reproducer:

nix-build -A pkgsStatic.haskell.packages.ghc98.th-orphans

error: builder for '/nix/store/dibiy3qjbg2l5ahlqf28axfqz5xw91xn-th-orphans-static-x86_64-unknown-linux-musl-0.13.14.drv' failed with exit code 1;
       last 10 log lines:
       > /nix/store/20rsi77ny2i4i1rbd63h4392a245j5dz-gnutar-1.35/bin/tar
       > No uhc found
       > Running phase: buildPhase
       > Preprocessing library for th-orphans-0.13.14..
       > Building library for th-orphans-0.13.14..
       > [1 of 2] Compiling Language.Haskell.TH.Instances.Internal ( src/Language/Haskell/TH/Instances/Internal.hs, dist/build/Language/Haskell/TH/Instances/Internal.o )
       > [2 of 2] Compiling Language.Haskell.TH.Instances ( src/Language/Haskell/TH/Instances.hs, dist/build/Language/Haskell/TH/Instances.o )
       >
       > <no location info>: error:
       >     Couldn't find a target code interpreter. Try with -fexternal-interpreter
       For full logs, run 'nix log /nix/store/dibiy3qjbg2l5ahlqf28axfqz5xw91xn-th-orphans-static-x86_64-unknown-linux-musl-0.13.14.drv'.

angerman · 2024-01-25T05:54:48Z

Even easier reproducer:

nix-build -A pkgsStatic.haskell.packages.ghc98.th-orphans

error: builder for '/nix/store/dibiy3qjbg2l5ahlqf28axfqz5xw91xn-th-orphans-static-x86_64-unknown-linux-musl-0.13.14.drv' failed with exit code 1;
       last 10 log lines:
       > /nix/store/20rsi77ny2i4i1rbd63h4392a245j5dz-gnutar-1.35/bin/tar
       > No uhc found
       > Running phase: buildPhase
       > Preprocessing library for th-orphans-0.13.14..
       > Building library for th-orphans-0.13.14..
       > [1 of 2] Compiling Language.Haskell.TH.Instances.Internal ( src/Language/Haskell/TH/Instances/Internal.hs, dist/build/Language/Haskell/TH/Instances/Internal.o )
       > [2 of 2] Compiling Language.Haskell.TH.Instances ( src/Language/Haskell/TH/Instances.hs, dist/build/Language/Haskell/TH/Instances.o )
       >
       > <no location info>: error:
       >     Couldn't find a target code interpreter. Try with -fexternal-interpreter
       For full logs, run 'nix log /nix/store/dibiy3qjbg2l5ahlqf28axfqz5xw91xn-th-orphans-static-x86_64-unknown-linux-musl-0.13.14.drv'.

That suggests that the GHC was not built as stage2 compiler, or some of the new cross target logic prohibits native codegen now as well.

peterbecich · 2024-10-31T04:35:29Z

Agree with #275304 (comment);

nix build nixpkgs#legacyPackages.x86_64-linux.pkgsStatic.haskell.packages.ghc9101.th-orphans

produces the error.

Additional example:

nix build nixpkgs#legacyPackages.x86_64-linux.pkgsCross.aarch64-multiplatform.haskell.packages.ghc9101.th-orphans

produces the error

nixos-discourse · 2024-10-31T04:38:29Z

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/build-aarch64-docker-image-on-amd64-machine/55052/5

peterbecich · 2024-11-01T05:36:46Z

These also produce the error
9.6

nix build nixpkgs/haskell-updates#legacyPackages.x86_64-linux.pkgsStatic.haskell.packages.ghc96.th-orphans_0_13_15

9.8

nix build nixpkgs/haskell-updates#legacyPackages.x86_64-linux.pkgsStatic.haskell.packages.ghc98.th-orphans_0_13_15

peterbecich · 2024-11-01T05:40:39Z

@bgamari, can we change the title to "GHC 9.6, 9.8, 9.10 TemplateHaskell doesn't work in pkgsStatic, pkgsCross"?

Namely: * Bump `ghc-wasm` flake to latest, which includes support for Template Haskell and macOS. Note that we now need to pass `-fno-external-interpreter` to GHC; this appears to be related to NixOS/nixpkgs#275304. * Run the Wasm build on macOS in CI, in addition to Linux. * Don't bother building Haddocks in the Wasm build. * Don't use `-fwrite-ide-info` in Wasm build. * `allow-newer` for `time` package. Signed-off-by: Drew Hess <src@drewhess.com>

sternenseemann · 2025-02-10T18:58:00Z

~~@wolfgangwalther GHC 9.12.1 (at least) does build and install ghc-iserv and friends. The advantage pkgsStatic has is that GHC's configure script never detects that we are, in fact, cross compiling.~~

sternenseemann · 2025-02-10T20:54:24Z

The haskell.nix builder for GHC work around this by sidestepping hadrians build and install process and doing it a bit more explicit.

https://github.com/input-output-hk/haskell.nix/blob/6eaafcdf04bab7be745d1aa4f74d2cc85700042b/compiler/ghc/default.nix#L787

I'm not even sure Hadrian can (or should be fixed). The proper solution seems to just bin it outright and build GHC with cabal only.

@angerman I don't understand how this works on the haskell.nix side. Even if you manually force the build of iserv and install it, isn't ghc still built without -finternal-interpreter and won't ever attempt to use the internal target code interpreter?

wolfgangwalther · 2025-02-15T15:50:06Z

@bgamari changed the title ~~GHC >= 9.6 TemplateHaskell doesn't work in pkgsStatic~~ GHC 9.6, 9.8, 9.10 TemplateHaskell doesn't work in pkgsStatic

Was this just as a reaction to #275304 (comment) or did you intentionally take 9.12 out of this, because it should do better?

We currently still get the same error for pkgsStatic.haskell.packages.ghc912.th-orphans:

       > <no location info>: error:
       >     Couldn't find a target code interpreter. Try with -fexternal-interpreter

Thus, changing back to "GHC >= 9.6".

If there is anything that was changed about this in 9.12, please let us know.

angerman · 2025-02-16T11:54:38Z

@angerman I don't understand how this works on the haskell.nix side. Even if you manually force the build of iserv and install it, isn't ghc still built without -finternal-interpreter and won't ever attempt to use the internal target code interpreter?

@sternenseemann I'm a bit confused. GHC should always be able to accept -fexternal-interpreter. I think it defaults to the internal if that is available, and -fexternal-interpreter isn't passed. Hence you can always pass -fexternal-interpreter for cross compilers (stage 1 or stage 2). Now for musl, where we basically build a ghc with an internal interpreter, yes, we shouldn't need iserv. haskell.nix though targets many more cross targets, and as such musl is just a very special case of cross for us. And we primarily tried to work around the insanity of Hadrian.

sternenseemann · 2025-02-16T16:09:36Z

So does that mean that the iserv hadrian package and the internal-interpreter flag of e.g. the ghc hadrian package are independent of each other?
That would be kind of good since technically we only need the internal interpreter to deal with this regression since nixpkgs doesn't do anything with iserv yet (#248979).

I've been able to clear up my question how haskell.nix achieves this since – it just disables the hadrian cross logic altogether.

angerman · 2025-02-18T11:09:57Z

@sternenseemann yes, isev is only needed for -fexternal-interpreter, if you have no intent of using the external interpreter (e.g. only using the internal-interpreter), you can disregard iserv outright.

wolfgangwalther · 2025-02-18T19:00:55Z

I made big progress with one observation: GHC thinks differently about "cross" than nixpkgs does.

For nixpkgs, just flipping isStatic = true is already considered cross, because hostPlatform != buildPlatform. But for GHC this would not be cross, yet. For GHC the triple must be different to consider it cross.

GHC only considers pkgsStatic cross, because we also switch to musl.

This can be observed in #383165. With this PR, it's possible to build ...

pkgsMusl.pkgsStatic.haskell.packages.native-bignum.ghc96.th-orphans

... just fine.

This expression compiles from "musl, shared libs" to "musl, static libs", so is not considered cross by GHC. Thus hadrian builds iserv and the internal-interpreter and whatnot... Template Haskell compiles fine.

Now, after fixing #383165, we have multiple options here:

We could just call it a day and build static haskell stuff on pkgsMusl.pkgsStatic... - I don't particularly like this option, because (a) nobody knows about it and (b) musl should just be an implementation detail. Maybe we can build static haskell stuff on FreeBSD or Darwin in the future?
We could switch pkgsStatic back to glibc and fix pkgsStatic shouldn't imply musl. #196329. Tbh: I don't think this is going to fly, that ship has sailed a long time ago. Also I tried, and we'd need to fix even more stuff first. Probably way more.
We could try to bootstrap pkgsStatic's GHC on Linux from a musl-built compiler. This would solve it nicely.

sternenseemann · 2025-02-19T22:41:14Z

@sternenseemann yes, isev is only needed for -fexternal-interpreter, if you have no intent of using the external interpreter (e.g. only using the internal-interpreter), you can disregard iserv outright.

@angerman Hm, but the internal-interpreter flag only has gotten disabled for cross relatively recently. GHC 9.8, for example, still would have it enabled when cross compiling:

$ /nix/store/dz660y60dym2rvg2d7zvbv2v1r3zpdvz-x86_64-unknown-linux-musl-ghc-native-bignum-9.8.4/bin/x86_64-unknown-linux-musl-ghc --info | grep interpreter
 ,("Use interpreter","YES")
 ,("Have interpreter","YES")

This is the same as we'd have with GHC 9.4. TemplateHaskellQuotes appears to work (we can build QuickCheck), but TemplateHaskell proper fails with the error message about the missing target code interpreter.

IIUC, this error message is only generated if hsc_interp is Nothing, but I can't, for the life of me, figure out how this gets set to Nothing after setTopSessionDynFlags if HAVE_INTERNAL_INTERPRETER is set.

angerman · 2025-02-21T08:48:36Z

@sternenseemann are you sure ghc can find iserv? You can pass the full path to iserv with -pgmi iirc.

sternenseemann · 2025-02-24T20:11:52Z

@angerman So I do need to build iserv?

I guess I'll need to have another look at the logic for the make build system. I've noticed that for the static cross compiler (x86_64-unknown-linux -> x86_64-unknown-linux-musl), GHC used to build iserv and GHCi which it won't anymore. hadrian (at least for 9.8) will still set the internal-interpreter flag for the ghc package, but neglect to build iserv and ghci. Unfortunately, I haven't yet figured out how to get it to build them (even with patching hadrian itself).

wolfgangwalther · 2025-02-24T20:37:10Z

hadrian (at least for 9.8) will still set the internal-interpreter flag for the ghc package, but neglect to build iserv and ghci. Unfortunately, I haven't yet figured out how to get it to build them (even with patching hadrian itself).

I was able to make it build those. Essentially it comes down to: Just tell hadrian that this is not a cross build and everything will fall into place. See last commit in #383165, that I just pushed. Still building for all the different versions, but I had a prototype build pkgsStatic...th-orphans successfully already.

Hadrian needs to know whether the Stage1 compiler will be able to run on the build machine to determine which libs and tools to build. However, the naive approach of comparing host vs target triple is insufficient for nixpkgs. The most prominent case is pkgsStatic on Linux, where the triple differs because of a different libc (glibc -> musl). But of course, we can still run the Stage1 compiler very well. Thus, we just tell Hadrian that this case is *not* cross, by fixing up configure to always return "no" when asked about cross compilation. Resolves NixOS#275304

sternenseemann · 2025-02-24T20:43:17Z

@wolfgangwalther Yes, that is essentially what haskell.nix does with a sledge hammer. I'm currently investigating whether we can possibly avoid this since it requires re-implementing parts of the cross logic ourselves or appeasing hadrian/autoconfs incorrect cross detection logic in cases like pkgsMusl.pkgsStatic. (Though of course, this whole TemplateHaskell business requires relying on stuff that one should not in case of proper cross…)

wolfgangwalther · 2025-02-24T20:49:43Z

Yes, that is essentially what haskell.nix does with a sledge hammer.

Ha. That's precisely what I do as well...

I'm currently investigating whether we can possibly avoid this since it requires re-implementing parts of the cross logic ourselves

I don't think we can avoid cross logic entirely on our side. In fact, we have a lot of conditionals already. I think the approach currently taken in #383165 is possibly even cleaner: We always pass --target, we always prefix the binaries (even in the native case), we tell Hadrian when it should consider it as cross and when it should not. Most consistent in a way.

angerman · 2025-02-25T02:30:47Z

@angerman So I do need to build iserv?

If you don't have an internal-interperter capable GHC, yes. GHC will not build iserv on its own on-demand. Although hat's something my team is looking at (no timeline or guaranteed outcome yet though).

bgamari added the 0.kind: bug Something is broken label Dec 19, 2023

bgamari mentioned this issue Dec 19, 2023

Fully static Haskell executables - overview issue #43795

Open

60 tasks

rnhmjoj added the 6.topic: static Static builds (e.g. pkgsStatic) label Dec 19, 2023

sternenseemann added this to Haskell infrastructure in nixpkgs enhancements Dec 19, 2023

sternenseemann moved this to Regression in Haskell infrastructure in nixpkgs enhancements Dec 19, 2023

sternenseemann added 6.topic: haskell 0.kind: regression Something that worked before working no longer and removed 0.kind: bug Something is broken labels Dec 19, 2023

sternenseemann moved this from Regression to In Progress in Haskell infrastructure in nixpkgs enhancements Dec 20, 2023

sternenseemann linked a pull request Dec 20, 2023 that will close this issue

pkgsStatic.haskell.packages.ghc98: disable failing haddockPhase #275609

Merged

13 tasks

maralorn closed this as completed in #275609 Jan 1, 2024

github-project-automation bot moved this from In Progress to Done in Haskell infrastructure in nixpkgs enhancements Jan 1, 2024

domenkozar mentioned this issue Jan 23, 2024

Provide middle-ground overlay between pkgsMusl and pkgsStatic #61575

Open

domenkozar reopened this Jan 24, 2024

peterbecich mentioned this issue Nov 3, 2024

link issue domenkozar/nixpkgs-static-repo#2

Open

dhess mentioned this issue Nov 3, 2024

chore: improved Wasm support hackworthltd/primer#1297

Merged

sternenseemann changed the title ~~GHC 9.8 TemplateHaskell doesn't work in pkgsStatic~~ GHC >= 9.8 TemplateHaskell doesn't work in pkgsStatic Nov 19, 2024

wolfgangwalther changed the title ~~GHC >= 9.8 TemplateHaskell doesn't work in pkgsStatic~~ GHC >= 9.6 TemplateHaskell doesn't work in pkgsStatic Jan 19, 2025

wolfgangwalther mentioned this issue Jan 19, 2025

haskellPackages: Stackage LTS 22 -> 23; ghc: 9.6.6 -> 9.8.4 #371032

Draft

wolfgangwalther mentioned this issue Jan 27, 2025

Build static executable for linux aarch64 PostgREST/postgrest#3866

Draft

bgamari changed the title ~~GHC >= 9.6 TemplateHaskell doesn't work in pkgsStatic~~ GHC 9.6, 9.8, 9.10 TemplateHaskell doesn't work in pkgsStatic Feb 7, 2025

wolfgangwalther changed the title ~~GHC 9.6, 9.8, 9.10 TemplateHaskell doesn't work in pkgsStatic~~ GHC >= 9.6 TemplateHaskell doesn't work in pkgsStatic Feb 15, 2025

s-and-witch mentioned this issue Feb 17, 2025

pkgsStatic.haskell.compiler.*: unable to install any compiler that is newer than ghc948 #382735

Open

3 tasks

wolfgangwalther mentioned this issue Feb 18, 2025

pkgsStatic.haskellPackages: fix TemplateHaskell #383165

Open

8 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GHC >= 9.6 TemplateHaskell doesn't work in pkgsStatic #275304

GHC >= 9.6 TemplateHaskell doesn't work in pkgsStatic #275304

bgamari commented Dec 19, 2023 •

edited

Loading

bgamari commented Dec 19, 2023

angerman commented Dec 19, 2023

rnhmjoj commented Dec 19, 2023

sternenseemann commented Dec 19, 2023

sternenseemann commented Dec 19, 2023

bgamari commented Dec 19, 2023 •

edited

Loading

sternenseemann commented Dec 19, 2023 •

edited

Loading

sternenseemann commented Dec 19, 2023

angerman commented Dec 20, 2023

sternenseemann commented Dec 20, 2023

angerman commented Dec 20, 2023

domenkozar commented Jan 24, 2024 •

edited

Loading

domenkozar commented Jan 24, 2024

angerman commented Jan 25, 2024

peterbecich commented Oct 31, 2024

nixos-discourse commented Oct 31, 2024

peterbecich commented Nov 1, 2024 •

edited

Loading

peterbecich commented Nov 1, 2024 •

edited

Loading

sternenseemann commented Feb 10, 2025 •

edited

Loading

sternenseemann commented Feb 10, 2025

wolfgangwalther commented Feb 15, 2025

angerman commented Feb 16, 2025

sternenseemann commented Feb 16, 2025

angerman commented Feb 18, 2025

wolfgangwalther commented Feb 18, 2025

sternenseemann commented Feb 19, 2025

angerman commented Feb 21, 2025

sternenseemann commented Feb 24, 2025

wolfgangwalther commented Feb 24, 2025

sternenseemann commented Feb 24, 2025

wolfgangwalther commented Feb 24, 2025

angerman commented Feb 25, 2025

GHC >= 9.6 TemplateHaskell doesn't work in pkgsStatic #275304

GHC >= 9.6 TemplateHaskell doesn't work in pkgsStatic #275304

Comments

bgamari commented Dec 19, 2023 • edited Loading

Describe the bug

Steps To Reproduce

Expected behavior

Observed behavior

Additional context

Notify maintainers

bgamari commented Dec 19, 2023

angerman commented Dec 19, 2023

rnhmjoj commented Dec 19, 2023

sternenseemann commented Dec 19, 2023

sternenseemann commented Dec 19, 2023

bgamari commented Dec 19, 2023 • edited Loading

sternenseemann commented Dec 19, 2023 • edited Loading

sternenseemann commented Dec 19, 2023

angerman commented Dec 20, 2023

sternenseemann commented Dec 20, 2023

angerman commented Dec 20, 2023

domenkozar commented Jan 24, 2024 • edited Loading

domenkozar commented Jan 24, 2024

angerman commented Jan 25, 2024

peterbecich commented Oct 31, 2024

nixos-discourse commented Oct 31, 2024

peterbecich commented Nov 1, 2024 • edited Loading

peterbecich commented Nov 1, 2024 • edited Loading

sternenseemann commented Feb 10, 2025 • edited Loading

sternenseemann commented Feb 10, 2025

wolfgangwalther commented Feb 15, 2025

angerman commented Feb 16, 2025

sternenseemann commented Feb 16, 2025

angerman commented Feb 18, 2025

wolfgangwalther commented Feb 18, 2025

sternenseemann commented Feb 19, 2025

angerman commented Feb 21, 2025

sternenseemann commented Feb 24, 2025

wolfgangwalther commented Feb 24, 2025

sternenseemann commented Feb 24, 2025

wolfgangwalther commented Feb 24, 2025

angerman commented Feb 25, 2025

bgamari commented Dec 19, 2023 •

edited

Loading

bgamari commented Dec 19, 2023 •

edited

Loading

sternenseemann commented Dec 19, 2023 •

edited

Loading

domenkozar commented Jan 24, 2024 •

edited

Loading

peterbecich commented Nov 1, 2024 •

edited

Loading

peterbecich commented Nov 1, 2024 •

edited

Loading

sternenseemann commented Feb 10, 2025 •

edited

Loading