Cheng Shao

@microsoft-github-policy-service agree

@mpickering I don't have time to push forwards a proper Cabal fix, though I did put up https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12548 at your convenience. Sorry for the breakage :/

that's a regression in upstream 9.12.3-rc1; the wasm releases are always rebased on upstream release branches. also see https://gitlab.haskell.org/ghc/head.hackage/-/blob/master/patches/ghc-lib-parser-9.12.2.20250421.patch#L31

a `source-repository-package` for the time being; though maybe doing an upstream hackage release on the 9.12 branch would solve this?

Note that `ghc-wasm-meta` works by pulling binary artifacts and repackaging them as nix derivations. Now, it's also possible to build GHC from source in nix, specifying any GHC revision with...

It would be very nice to make `wasm-component-ld` building logic optional, since downstream users may have other ways to provide the rust based tools and want to avoid `cargo install`...

@alexcrichton Nope, just assuming `wasm-component-ld` is already built elsewhere and present in `PATH`. That shouldn't affect p2 sysroots.

I figured it out; one needs to pass `-a` `program-locations\n ar-location: /bin/my-custom-ar` to apply the diff. So the bug should be `cabal user-config diff` outputing a clearer diff which works...

`directory-1.3.8.4` as shipped in ghc head.

`openFile` with `AppendMode` in wasm backend is only recently fixed by https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11697 (see `openFile009` test case), though `ghc-wasm-meta`'s `master` branch has been stalled for a while because of a `wasi-sdk`...