haskell packages with separate bin outputs fail due to a reference cycle on aarch64-darwin #140774

walkah · 2021-10-06T16:35:39Z

Describe the bug

niv fails to build on aarch64-darwin with the following errors:

Linking dist/build/niv/niv ...
running tests
Running 1 test suites...
Test suite unit: RUNNING...
Test suite unit: PASS
Test suite logged to: dist/test/niv-0.2.19-unit.log
1 of 1 test suites (1 of 1 test cases) passed.
haddockPhase
installing
Installing library in /nix/store/v5p7lliij8f10c920sa8lwnqv8di6007-niv-0.2.19/lib/ghc-8.10.7/aarch64-osx-ghc-8.10.7/niv-0.2.19-HYXnAgZhF2cLmqAJFPpkgw
Installing executable niv in /nix/store/abawbski981061gbsnq0v5374gvsrbq7-niv-0.2.19-bin/bin
Warning: The directory
/nix/store/abawbski981061gbsnq0v5374gvsrbq7-niv-0.2.19-bin/bin is not in the
system search path.
/nix/store/mp5xsfnvdbdyqjmcipyks4nph534jc3q-cctools-binutils-darwin-949.0.1/bin/strip: changes being made to the file will invalidate the code signature in: /nix/store/abawbski981061gbsnq0v5374gvsrbq7-niv-0.2.19-bin/bin/niv
Registering library for niv-0.2.19..
post-installation fixup
strip is /nix/store/vf55lp3k5xgx1vlkysb7pbw76f1wh21l-clang-wrapper-11.1.0/bin/strip
stripping (with command strip and flags -S) in /nix/store/v5p7lliij8f10c920sa8lwnqv8di6007-niv-0.2.19/lib
patching script interpreter paths in /nix/store/v5p7lliij8f10c920sa8lwnqv8di6007-niv-0.2.19
strip is /nix/store/vf55lp3k5xgx1vlkysb7pbw76f1wh21l-clang-wrapper-11.1.0/bin/strip
patching script interpreter paths in /nix/store/hkapz2a124mmzc3x1mw2dqvds3bhkfg4-niv-0.2.19-data
strip is /nix/store/vf55lp3k5xgx1vlkysb7pbw76f1wh21l-clang-wrapper-11.1.0/bin/strip
stripping (with command strip and flags -S) in /nix/store/abawbski981061gbsnq0v5374gvsrbq7-niv-0.2.19-bin/bin
patching script interpreter paths in /nix/store/abawbski981061gbsnq0v5374gvsrbq7-niv-0.2.19-bin
cycle detected in the references of '/nix/store/abawbski981061gbsnq0v5374gvsrbq7-niv-0.2.19-bin' from '/nix/store/v5p7lliij8f10c920sa8lwnqv8di6007-niv-0.2.19'
error: build of '/nix/store/k1jbc0389f58cwwy9xvi9r2xi5fmqdc2-niv-0.2.19.drv' failed

Recent hydra builds also fail: https://hydra.nixos.org/job/nixpkgs/nixpkgs-unstable-aarch64-darwin/niv.aarch64-darwin

Steps To Reproduce

Steps to reproduce the behavior:

nix-shell -p niv

Expected behavior

niv should install and be available.

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"aarch64-darwin"`
 - host os: `Darwin 20.6.0, macOS 11.6`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.3.15`
 - channels(walkah): `"darwin, home-manager"`
 - channels(root): `"nixpkgs-21.11pre320922.ee084c02040"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

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

sternenseemann · 2021-10-06T21:51:49Z

See also #140180 for the same issue. Seems like haskell packages with separate bin outputs just don't work on aarch64-darwin for some reason, likely codesigning?!

sternenseemann · 2021-11-23T15:39:18Z

@NixOS/darwin-maintainers please can someone look into this issue? I literally have no way of debugging this.

starcraft66 · 2021-11-23T16:23:21Z

I attempted to build niv with enableSeparateDataOutput = false; and still get the same error. I haven't touched haskellPackages before and I'm extremely unfamiliar as to how the outputs are created and how the relate to eachother in a way that creates a loop.

onthestairs · 2021-11-23T17:32:20Z

Setting enableSeparateBinOutput = false; (bin not data) worked for me, but I'm also quite unfamiliar with how things work so it was a bit of a guess.

sternenseemann · 2021-11-23T17:35:44Z

Well, that's an obvious workaround, what I'm more interested in is why do bin outputs in haskell packages create cyclical dependencies between outputs only on aarch64-darwin.

toonn · 2021-11-23T18:56:09Z

Which references are causing the cycles? Is it something like an extra codesigning binary in bin which is also used from out?

While GHC now can be bootstrapped and built on aarch64-darwin, it seems to work only to an extent. All sorts of strange issues have manifested themselves in `haskellPackages` and downstream usage which leads me to conclude that it would be misleading to call it supported on this platform, especially in a stable channel. To give a few examples, separate bin outputs just don't work in general [1] and `opt` fails for unknown reasons in some derivations [2]. As I don't own any appropriate hardware, I have tried tackling these issues by staring into my crystal ball, but so far to no avail (even worse, new issues [3] have cropped up due to changes that should have been an improvement). Given these circumstances, I'm not willing to call GHC supported on aarch64-darwin for the stable channel. I'm (for now) hopeful that we can improve the situation on `master` going forward, but it is not guaranteed that these changes will be backportable without a ton of effort. Should it turn out that we can't resolve these issues or maintain GHC's aarch64-darwin support due to a lack of contributors going forward, I am also prepared to drop aarch64-darwin support completely. While it has been proclaimed a Tier 3 platform, I would argue that the “popular” package GHC has never been working, at least not properly. [1]: NixOS#140774 NixOS#140180 [2]: https://matrix.to/#/!RbXGJhHMsnQcNIDFWN:nixos.org/$C6FK74EajqSTk58JzriYpQJ9f6x3UH3tIREcn04Y-rM?via=nixos.org&via=matrix.org&via=tchncs.de [3]: srid/haskell-template#1 (comment)

cideM · 2021-12-02T09:11:19Z

I'm seeing this issue in a Nix shell with ghcid and ormolu. I'll look into this a little more in the evening but at least to me it seems like this affects more than just a single package

sternenseemann · 2021-12-02T09:12:44Z

Yes, every haskell package with a separate bin output is broken at the moment. Would be great to find out what actually causes the reference cycle.

cideM · 2021-12-02T13:37:04Z

I think we should change the title of the issue to reflect the broader scope. I tried bisecting on my M1 machine earlier but build times are brutal for all the Haskell machinery. I might have to try a different approach later on. I did check if otool -l path/to/ghcid-bin references anything from the ghcid lib output but it did not. Which is strange because then what's responsible for the circular reference? Anyhow, will look into this more later.

hexagonal-sun · 2021-12-03T09:40:02Z

I can upload the failed build directory of ormolu (a failing haskell package) being built on aarch64-darwin if that helps?

sternenseemann · 2021-12-03T10:05:35Z

I can upload the failed build directory of ormolu (a failing haskell package) being built on aarch64-darwin if that helps?

This is of limited use because it doesn't really tell you what is wrong in the installed outputs. I'd expect that the references get introduced in fixupPhase which is after installation… I guess you could grep for the value of niv.bin.outPath and nix.out.outPath in the build directory and see if it turns up something interesting.

This nix feature would be useful right about now…

hexagonal-sun · 2021-12-03T10:14:38Z

I can upload the failed build directory of ormolu (a failing haskell package) being built on aarch64-darwin if that helps?

This is of limited use because it doesn't really tell you what is wrong in the installed outputs. I'd expect that the references get introduced in fixupPhase which is after installation… I guess you could grep for the value of niv.bin.outPath and nix.out.outPath in the build directory and see if it turns up something interesting.

This nix feature would be useful right about now…

If I do: nix show-derivation /nix/store/120xvbzmkglal2zgq43bx8n82cn3q8h5-ghcid-0.8.7.drv I can see the output directories in the store:

{
  "/nix/store/120xvbzmkglal2zgq43bx8n82cn3q8h5-ghcid-0.8.7.drv": {
    "outputs": {
      "bin": {
        "path": "/nix/store/781rfvh4fb9wjz33zr5y1nfli1fv5yzp-ghcid-0.8.7-bin"
      },
      "doc": {
        "path": "/nix/store/27ik61ijjsgjga35g5n021l8j30fqf6g-ghcid-0.8.7-doc"
      },
      "out": {
        "path": "/nix/store/wihaahmwj1hksyf117dqvi6s249dg23v-ghcid-0.8.7"
      }
    },
 
[...]

Those directories do have the built binaries in libs in there. Would that be of more use? i.e, would the fixupPhase have occurred at that point?

hexagonal-sun · 2021-12-03T15:28:35Z

I've been doing a bit more digging on this and after running nix build --debug --keep-failed ".#ghcid", I found the following:

scanning for references for output 'bin' in temp location '/nix/store/781rfvh4fb9wjz33zr5y1nfli1fv5yzp-ghcid-0.8.7-bin'
found reference to 'w8079fmkwpblbcpj0vyaaj49l1ib8q95' at offset '2043'
found reference to 'hchnpr6dwnq47c2m5mm7i65wxx3cdhmi' at offset '2147'
found reference to 'f42zzy8y0fjc2fsfxs4ylpd6wxzgmx04' at offset '2251'
found reference to 'l0rp423b2w8b065w5cdx4s3hanjx464x' at offset '2431'
found reference to '781rfvh4fb9wjz33zr5y1nfli1fv5yzp' at offset '45769'
found reference to 'wihaahmwj1hksyf117dqvi6s249dg23v' at offset '45846' [lib output]
scanning for references for output 'doc' in temp location '/nix/store/27ik61ijjsgjga35g5n021l8j30fqf6g-ghcid-0.8.7-doc'
found reference to 'rffixa56qdb6vrrn85m9434r6nnyz7nc' at offset '2029'
found reference to 'hwzhi4m3mr6y3raq12xhf3wqi36qpf08' at offset '3588'
found reference to 'zh7w4sk7kkry40gp02hry61fhgrfagsw' at offset '5388'
found reference to '43zgrl31xb6brandd5vn729ijfdnq7qj' at offset '8128'
found reference to '781rfvh4fb9wjz33zr5y1nfli1fv5yzp' at offset '11537'
scanning for references for output 'out' in temp location '/nix/store/wihaahmwj1hksyf117dqvi6s249dg23v-ghcid-0.8.7'
found reference to 'hrwkdw342mxc1y5a0czf5x8zsrn7svp0' at offset '402'
found reference to '781rfvh4fb9wjz33zr5y1nfli1fv5yzp' at offset '1668' [bin output]
found reference to 'wihaahmwj1hksyf117dqvi6s249dg23v' at offset '2944'
found reference to 'w8079fmkwpblbcpj0vyaaj49l1ib8q95' at offset '2319'
found reference to 'hchnpr6dwnq47c2m5mm7i65wxx3cdhmi' at offset '3327'
found reference to 'f42zzy8y0fjc2fsfxs4ylpd6wxzgmx04' at offset '3791'
[...]

I'm not too sure how these references are found, but I presume that it's doing something similar to running strings across the binary and looking for a valid nix store hash. If that's the case. The reference from bin to out:

@platoon:/n/s/7/bin🔒 ❯ strings ghcid | grep store
/nix/store/w8079fmkwpblbcpj0vyaaj49l1ib8q95-libiconv-50/lib/libiconv.dylib
/nix/store/hchnpr6dwnq47c2m5mm7i65wxx3cdhmi-gmp-6.2.1/lib/libgmp.10.dylib
/nix/store/f42zzy8y0fjc2fsfxs4ylpd6wxzgmx04-libffi-3.4.2/lib/libffi.8.dylib
/nix/store/l0rp423b2w8b065w5cdx4s3hanjx464x-apple-framework-CoreFoundation-11.0.0/Library/Frameworks
/nix/store/781rfvh4fb9wjz33zr5y1nfli1fv5yzp-ghcid-0.8.7-bin/bin
[references to out follow]
/nix/store/wihaahmwj1hksyf117dqvi6s249dg23v-ghcid-0.8.7/lib/ghc-8.10.7/aarch64-osx-ghc-8.10.7/ghcid-0.8.7-5ZcL75a2atNERQtuLKeyuL-ghcid
/nix/store/wihaahmwj1hksyf117dqvi6s249dg23v-ghcid-0.8.7/lib/ghc-8.10.7/aarch64-osx-ghc-8.10.7
/nix/store/wihaahmwj1hksyf117dqvi6s249dg23v-ghcid-0.8.7/share/aarch64-osx-ghc-8.10.7/ghcid-0.8.7
/nix/store/wihaahmwj1hksyf117dqvi6s249dg23v-ghcid-0.8.7/libexec/aarch64-osx-ghc-8.10.7/ghcid-0.8.7
/nix/store/wihaahmwj1hksyf117dqvi6s249dg23v-ghcid-0.8.7/etc

The reference from out to bin:

@platoon:/n/s/w/l/g/aarch64-osx-ghc-8.10.7🔒 ❯ strings libHSghcid-0.8.7-Eq9Lb7GjR4QBjEa2ZCK5Kw-ghc8.10.7.dylib | grep store           
[...]
/nix/store/hrwkdw342mxc1y5a0czf5x8zsrn7svp0-ghc-8.10.7/lib/ghc-8.10.7/unix-2.7.2.2
/nix/store/wihaahmwj1hksyf117dqvi6s249dg23v-ghcid-0.8.7/lib/links
/nix/store/l0rp423b2w8b065w5cdx4s3hanjx464x-apple-framework-CoreFoundation-11.0.0/Library/Frameworks
[reference to bin follows]
/nix/store/781rfvh4fb9wjz33zr5y1nfli1fv5yzp-ghcid-0.8.7-bin/bin
/nix/store/wihaahmwj1hksyf117dqvi6s249dg23v-ghcid-0.8.7/lib/ghc-8.10.7/aarch64-osx-ghc-8.10.7/ghcid-0.8.7-Eq9Lb7GjR4QBjEa2ZCK5Kw

Having a reference from bin -> out makes sense, the more curious case is the reference from out -> bin. Strangely, it looks as though it's only referencing the bin folder, not the actual ghcid executable.

sternenseemann · 2021-12-03T16:05:16Z

Actually the bin -> out reference is probably the anomaly since the executable should be statically linked (against the haskell libraries, system deps are linked dynamically) and thus contain no reference to the library.

I wonder how the reference comes into existence…

hexagonal-sun · 2021-12-04T07:47:18Z

@sternenseemann Indeed, you are correct. I've just checked on my x86_darwin system and there is a reference from out -> bin but no reference from bin -> out, so it looks as though the ghcid binary is the problem. I've uploaded it here for other people to take a look at, but I'll see if I can figure out where the reference is coming from. The bad references can be seen with strings ghcid | grep wihaahmwj1hksyf1.

ghcid-bin-aarch64-darwin.tar.gz

Update:
After throwing the binary into ghidra to see where the referencies are coming from , it looks as though they are values of the haskell functions: getLibDir, getDynLibDir, getDataDir, getLibexecDir, getSysconfDir:

These symbols don't exist in the x86_64-darwin binary.

domenkozar · 2021-12-05T12:51:23Z

Maybe we can just make bin output a no-op on aarch64-darwin until it's fixed?

sternenseemann · 2021-12-05T17:33:39Z

I'm against this for the simple reason it eliminates any incentive to fix the bug. Separate bin outputs are quite important as they significantly reduce the closure size: Haskell binaries are statically linked, so the download of the libraries plus the entire dependency closure is unnecessary if you only want to execute a tool.

Given Rosetta, there is a decent enough workaround for the failing builds.

domenkozar · 2021-12-05T18:31:25Z

Separate bin outputs are quite important as they significantly reduce the closure size: Haskell binaries are statically linked, so the download of the libraries plus the entire dependency closure is unnecessary if you only want to execute a tool.

That's the incentive :)

srid · 2023-02-11T20:14:49Z

@balacij "Killed" in the error message suggests that the kernel killed the build process? Out of memory?

By the way, for anyone that uses haskell-flake, I have just created a module making it easier to incorporate the workaround for this bug in their Haskell projects: https://github.com/srid/nixpkgs-140774-workaround

🚀

balacij · 2023-02-11T20:27:20Z

Hi @srid, thank you. Yes, it seemingly continuously rebuilds the plugins for haskell-language-server until my computer runs out of memory and kills the build.

sloane-shark · 2023-02-19T13:47:42Z

I revived/reworked the PR to workaround this for 9.2.x releases: #216857

The main change here is enabling the separate `bin` output for `ormolu`, which is currently necessary to get HLS working on `aarch64-darwin`. See: NixOS/nixpkgs#140774 (comment) Adding in the overlay to fix that entailed some surgery to `ghc.nix` and `flake.nix`, but I tried my best to make it as unintrusive as possible.

commit a9d9ac2 Merge: 80f2ab3 c686098 Author: Gabriella Gonzalez <[email protected]> Date: Tue Feb 21 16:36:19 2023 -0800 Merge branch 'master' into gabriella/fix_build commit 80f2ab3 Author: Gabriella Gonzalez <[email protected]> Date: Fri Feb 10 10:29:37 2023 -0800 Fix hash commit 46dc419 Merge: 2d2b8e8 84e4f9c Author: Gabriella Gonzalez <[email protected]> Date: Fri Feb 10 10:04:33 2023 -0800 Merge branch 'master' into gabriella/fix_build commit 2d2b8e8 Author: Gabriella Gonzalez <[email protected]> Date: Thu Feb 2 12:50:40 2023 -0800 Fix build failures on `aarch64-darwin` The main change here is enabling the separate `bin` output for `ormolu`, which is currently necessary to get HLS working on `aarch64-darwin`. See: NixOS/nixpkgs#140774 (comment) Adding in the overlay to fix that entailed some surgery to `ghc.nix` and `flake.nix`, but I tried my best to make it as unintrusive as possible.

The main change here is enabling the separate `bin` output for `ormolu`, which is currently necessary to get HLS working on `aarch64-darwin`. See: NixOS/nixpkgs#140774 (comment) Adding in the overlay to fix that entailed some surgery to `ghc.nix` and `flake.nix`, but I tried my best to make it as unintrusive as possible.

shinzui · 2023-03-01T01:16:04Z

@matthewess Does this fix also work on 9.4.x?

sloane-shark · 2023-03-01T02:25:20Z

@shinzui I haven't tested it myself, you could check out my PR and try applying the patch to the appropriate configuration-ghc-9.4.x.nix file or whatnot

adrian-gierakowski · 2023-03-11T14:11:21Z

🎉

This ports our infamous patch for `Cabal` which cheesily prevents an output cycle for derivations that use separate bin outputs where references caused by the `Paths_*` module can't be eliminated by the GHC aarch64-darwin codegen backend. See also - the original issue NixOS#140774, - the original patch for GHC 9.2 NixOS#216857 - the ported patch for GHC 9.4 NixOS@f6f780f Co-authored-by: sternenseemann <[email protected]>

This ports our infamous patch for `Cabal` which cheesily prevents an output cycle for derivations that use separate bin outputs where references caused by the `Paths_*` module can't be eliminated by the GHC aarch64-darwin codegen backend. See also - the original issue #140774, - the original patch for GHC 9.2 #216857 - the ported patch for GHC 9.4 f6f780f Co-authored-by: sternenseemann <[email protected]>

This ports our infamous patch for Cabal that prevents certain parts of the Paths_* module from being generated in order to prevent unnecessary references on aarch64-darwin, to GHC >= 9.10. See also: - Original issues: #140774 - Patches - Original patch for GHC >= 8.10 && < 9.2 / Cabal >= 3.2 && < 3.6: b0dcd7f - Patch for GHC >= 9.2 && < 9.10 / Cabal >= 3.6 && < 3.12: #216857, f6f780f129f50df536fb30, …

This ports our infamous patch for Cabal that prevents certain parts of the Paths_* module from being generated in order to prevent unnecessary references on aarch64-darwin, to GHC >= 9.10. See also: - Original issues: #140774 - Patches - Original patch for GHC >= 8.10 && < 9.2 / Cabal >= 3.2 && < 3.6: b0dcd7f - Patch for GHC >= 9.2 && < 9.10 / Cabal >= 3.6 && < 3.12: #216857, f6f780f129f50df536fb30, … (cherry picked from commit 3885dfe)

walkah added the 0.kind: bug Something is broken label Oct 6, 2021

walkah changed the title ~~niv fails to build on aarch64-darwins~~ niv fails to build on aarch64-darwin Oct 6, 2021

sternenseemann added 6.topic: darwin Running or building packages on Darwin 6.topic: haskell labels Oct 6, 2021

arkivm mentioned this issue Nov 3, 2021

[aarch64-darwin] niv fails to build #144187

Closed

sternenseemann mentioned this issue Nov 30, 2021

[21.11] haskell.compiler.*: mark as unsupported on aarch64-darwin #147964

Closed

13 tasks

sternenseemann changed the title ~~niv fails to build on aarch64-darwin~~ haskell packages with separate bin outputs fail due to a reference cycle on aarch64-darwin Dec 2, 2021

sternenseemann mentioned this issue Dec 2, 2021

haskell-language-server doesn't build on aarch64-darwin #140180

Closed

ryantm mentioned this issue Dec 2, 2021

Installation fails at Update dependencies with "cannot coerce null to a string" ryantm/home-manager-template#8

Open

rockofox mentioned this issue Feb 14, 2023

fix nixpkgs#140774 on aarch64-darwin ners/dosh#3

Closed

sloane-shark mentioned this issue Feb 17, 2023

Add cabal-paths patch for ghc 9.2.x #216857

Merged

12 tasks

Patryk27 mentioned this issue Feb 25, 2023

Build cycle detected when using niv on darwin-aarch64(M1) with unstable #217549

Closed

sternenseemann closed this as completed Mar 11, 2023

github-project-automation bot moved this from In Progress to Done in Haskell infrastructure in nixpkgs enhancements Mar 11, 2023

sternenseemann mentioned this issue Mar 11, 2023

Port patch fixing cabal Paths_* module caused reference cycle on aarch64-darwin to GHC 9.4 #220647

Closed

tadfisher mentioned this issue Oct 17, 2023

Update build for GHC 9.6.+ MercuryTechnologies/moat#71

Merged

mpscholten mentioned this issue Nov 4, 2023

haskell.compiler.ghc9{6,8}: work around output cycles on aarch64-darwin #258280

Merged

12 tasks

moonshxne mentioned this issue Dec 12, 2023

Changes to build GHC 9.8 (and HLS) on aarch64-darwin #273710

Closed

13 tasks

chris-martin mentioned this issue May 30, 2024

add arm to the build matrix freckle/flakes#35

Merged

sternenseemann mentioned this issue May 31, 2024

haskell.packages.ghc910: work around aarch64-darwin output cycles #316157

Merged

13 tasks

sternenseemann mentioned this issue Jun 7, 2024

Haskell binaries with excessive closure sizes on aarch64-darwin #318013

Open

11 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

haskell packages with separate bin outputs fail due to a reference cycle on aarch64-darwin #140774

haskell packages with separate bin outputs fail due to a reference cycle on aarch64-darwin #140774

walkah commented Oct 6, 2021

sternenseemann commented Oct 6, 2021

sternenseemann commented Nov 23, 2021

starcraft66 commented Nov 23, 2021

onthestairs commented Nov 23, 2021 •

edited

Loading

sternenseemann commented Nov 23, 2021

toonn commented Nov 23, 2021

cideM commented Dec 2, 2021

sternenseemann commented Dec 2, 2021

cideM commented Dec 2, 2021 •

edited

Loading

hexagonal-sun commented Dec 3, 2021

sternenseemann commented Dec 3, 2021 •

edited

Loading

hexagonal-sun commented Dec 3, 2021 •

edited

Loading

hexagonal-sun commented Dec 3, 2021 •

edited

Loading

sternenseemann commented Dec 3, 2021

hexagonal-sun commented Dec 4, 2021 •

edited

Loading

domenkozar commented Dec 5, 2021

sternenseemann commented Dec 5, 2021

domenkozar commented Dec 5, 2021

srid commented Feb 11, 2023 •

edited

Loading

balacij commented Feb 11, 2023 •

edited

Loading

sloane-shark commented Feb 19, 2023

shinzui commented Mar 1, 2023

sloane-shark commented Mar 1, 2023

adrian-gierakowski commented Mar 11, 2023

haskell packages with separate bin outputs fail due to a reference cycle on aarch64-darwin #140774

haskell packages with separate bin outputs fail due to a reference cycle on aarch64-darwin #140774

Comments

walkah commented Oct 6, 2021

Describe the bug

Steps To Reproduce

Expected behavior

Metadata

sternenseemann commented Oct 6, 2021

sternenseemann commented Nov 23, 2021

starcraft66 commented Nov 23, 2021

onthestairs commented Nov 23, 2021 • edited Loading

sternenseemann commented Nov 23, 2021

toonn commented Nov 23, 2021

cideM commented Dec 2, 2021

sternenseemann commented Dec 2, 2021

cideM commented Dec 2, 2021 • edited Loading

hexagonal-sun commented Dec 3, 2021

sternenseemann commented Dec 3, 2021 • edited Loading

hexagonal-sun commented Dec 3, 2021 • edited Loading

hexagonal-sun commented Dec 3, 2021 • edited Loading

sternenseemann commented Dec 3, 2021

hexagonal-sun commented Dec 4, 2021 • edited Loading

domenkozar commented Dec 5, 2021

sternenseemann commented Dec 5, 2021

domenkozar commented Dec 5, 2021

srid commented Feb 11, 2023 • edited Loading

balacij commented Feb 11, 2023 • edited Loading

sloane-shark commented Feb 19, 2023

shinzui commented Mar 1, 2023

sloane-shark commented Mar 1, 2023

adrian-gierakowski commented Mar 11, 2023

onthestairs commented Nov 23, 2021 •

edited

Loading

cideM commented Dec 2, 2021 •

edited

Loading

sternenseemann commented Dec 3, 2021 •

edited

Loading

hexagonal-sun commented Dec 3, 2021 •

edited

Loading

hexagonal-sun commented Dec 3, 2021 •

edited

Loading

hexagonal-sun commented Dec 4, 2021 •

edited

Loading

srid commented Feb 11, 2023 •

edited

Loading

balacij commented Feb 11, 2023 •

edited

Loading