GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-27T12:34:17Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24554ghc-9.10.0.20240313 (alpha1) does not install on macOS2024-03-27T12:34:17ZAndreas Abelghc-9.10.0.20240313 (alpha1) does not install on macOSIssue #21506 is back for 9.10-alpha1. Same description, same symptoms, probably same cure.
Spelling it out:
- macOS Monterey 12.7.1
- download https://downloads.haskell.org/~ghc/9.10.0.20240313/ghc-9.10.0.20240313-x86_64-apple-darwin.t...Issue #21506 is back for 9.10-alpha1. Same description, same symptoms, probably same cure.
Spelling it out:
- macOS Monterey 12.7.1
- download https://downloads.haskell.org/~ghc/9.10.0.20240313/ghc-9.10.0.20240313-x86_64-apple-darwin.tar.xz
- `tar xf ...; cd ghc-...; ./configure`
- Produces pop-ups stating that "`libHS...` was blocked, not from an identified developer"
Here is some detailed error, but this is probably not interesting, since it is really a reprise of #21506 only:
```
./configure: line 13507: 8575 Killed: 9 "$GHC_TOOLCHAIN_BIN" -v2 "$@"
dyld[8606]: Library not loaded: '@rpath/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib'
Referenced from: '/Users/abel/bin/soft/ghc-9.10.0.20240313-x86_64-apple-darwin/bin/ghc-toolchain-bin-ghc-9.10.0.20240313'
Reason: tried: '/Users/abel/bin/soft/ghc-9.10.0.20240313-x86_64-apple-darwin/bin/../lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (code signature in <665593BF-2381-30B1-A621-5A18BB60B521> '/Users/abel/bin/soft/ghc-9.10.0.20240313-x86_64-apple-darwin/lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' not valid for use in process: library load disallowed by system policy), '$ORIGIN/../../../lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (no such file), '/Users/abel/bin/soft/ghc-9.10.0.20240313-x86_64-apple-darwin/bin/../lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (code signature in <665593BF-2381-30B1-A621-5A18BB60B521> '/Users/abel/bin/soft/ghc-9.10.0.20240313-x86_64-apple-darwin/lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' not valid for use in process: library load disallowed by system policy), '$ORIGIN/../../../lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (no such file), '/usr/local/lib/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (no such file), '/usr/lib/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (no such file)
```
I would assume it is a packaging error.
See also #23009.
P.S.: Installation succeeds via `ghcup`, thus, not many will bump into this problem.
I dimly remember that `ghcup` implements a work-around (patching the file tree permissions before running installation).9.10.1Rodrigo MesquitaRodrigo Mesquitahttps://gitlab.haskell.org/ghc/ghc/-/issues/24546ghcup metadata gives incorrect dlSubdir of testsuite artifact2024-03-27T12:34:17ZBen Gamarighcup metadata gives incorrect dlSubdir of testsuite artifactAs noted in https://github.com/haskell/ghcup-metadata/pull/186#discussion_r1524064965, the `dlSubdir` of the testsuite artifact in the generated ghcup metadata is incorrect. It is listed as `dlSubdir: ghc-$ver` whereas it should be `dlSu...As noted in https://github.com/haskell/ghcup-metadata/pull/186#discussion_r1524064965, the `dlSubdir` of the testsuite artifact in the generated ghcup metadata is incorrect. It is listed as `dlSubdir: ghc-$ver` whereas it should be `dlSubdir: ghc-$ver/testsuite`.9.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24545GHC 9.10.1-alpha1 .tar.gz download does not extract properly2024-03-21T15:50:12ZRyan ScottGHC 9.10.1-alpha1 .tar.gz download does not extract properlyAfter downloading https://downloads.haskell.org/ghc/9.10.1-alpha1/ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.gz, I attempted to extract it, only to be thwarted by this error:
```
$ tar -xvf ghc-9.10.0.20240313-x86_64-fedora33-linux.t...After downloading https://downloads.haskell.org/ghc/9.10.1-alpha1/ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.gz, I attempted to extract it, only to be thwarted by this error:
```
$ tar -xvf ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.gz
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
```
Curiously, this only affects the `.tar.gz` download, as the [`.tar.xz` version](https://downloads.haskell.org/ghc/9.10.1-alpha1/ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.xz) extracts without issue. I haven't tried any other variants of GHC 9.10.1-alpha1.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/24529Binary distribution build on Windows fails2024-03-25T17:40:32ZBen GamariBinary distribution build on Windows failsIt appears that the `reloc-binary-dist` target is broken in at least some situations on Windows. Specifically, the `configure` invocation performed by `Rules.BinaryDist.installTo` fails to find the in-place mingw toolchain, causing `ghc-...It appears that the `reloc-binary-dist` target is broken in at least some situations on Windows. Specifically, the `configure` invocation performed by `Rules.BinaryDist.installTo` fails to find the in-place mingw toolchain, causing `ghc-toolchain` to conclude that there is no valid object merging tool available:
```
[Error {errorMessage = "Neither a object-merging tool (e.g. ld -r) nor an ar that supports -L is available", errorLogContexts = []}]
```
What is perplexing is that this appears to work in CI: the build system manages to produce a binary distribution, albeit a broken one for unrelated reasons (#24525).https://gitlab.haskell.org/ghc/ghc/-/issues/24525Windows bindists are quite broken2024-03-20T10:46:50ZBen GamariWindows bindists are quite brokenmingw32 binary distributions are currently quite broken:
```bash
$ wget https://gitlab.haskell.org/ghc/ghc/-/jobs/1805153/artifacts/raw/ghc-x86_64-windows-release.tar.xz
$ tar -xf ../ghc-x86_64-windows-release.tar.xz
$ cd ghc-9.10.0.2024...mingw32 binary distributions are currently quite broken:
```bash
$ wget https://gitlab.haskell.org/ghc/ghc/-/jobs/1805153/artifacts/raw/ghc-x86_64-windows-release.tar.xz
$ tar -xf ../ghc-x86_64-windows-release.tar.xz
$ cd ghc-9.10.0.20240310-x86_64-unknown-mingw32/
$ bin/ghc --info
ghc-9.10.0.20240310.exe: could not detect mingw toolchain in the following paths: ["C:\\msys64\\home\\ben\\tmp\\ghc-9.10.0.20240310-x86_64-unknown-mingw32\\lib\\..\\mingw","C:\\msys64\\home\\ben\\tmp\\ghc-9.10.0.20240310-x86_64-unknown-mingw32\\lib\\..\\..\\mingw","C:\\msys64\\home\\ben\\tmp\\ghc-9.10.0.20240310-x86_64-unknown-mingw32\\lib\\..\\..\\..\\mingw"]
```
It appears that many things that should be in the root of the binary distribution are instead now in `lib` (including `mingw/`):
```bash
$ ls lib/
a.exe config.guess config.status default.host.target.in doc ghc-usage.txt install-sh llvm-targets mk README x86_64-windows-ghc-9.10.0.20240310
bin config.log config.sub default.target docs-utils html latex Makefile package.conf.d settings
build.mk config.mk configure default.target.ghc-toolchain ghc-interp.js include lib manpage post-link.mjs template-hsc.h
completion config.mk.in default.host.target default.target.in ghci-usage.txt INSTALL llvm-passes mingw prelude.js wrappers
```
Moving `lib/mingw` to the root of the distribution appears to be sufficient to make the compiler functional.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/237889.8.0 binary-dist-dir creates name-ver-inplace library dirs2023-10-26T01:32:26ZJens Petersen9.8.0 binary-dist-dir creates name-ver-inplace library dirs## Summary
Previously (9.6 and earlier) with hadrian, core libraries were installed
in directories named name-version, but for 9.8.1-alpha1 there seems
to be a suffix added: my fedora build has `-inplace` appended
and I see short 4 char...## Summary
Previously (9.6 and earlier) with hadrian, core libraries were installed
in directories named name-version, but for 9.8.1-alpha1 there seems
to be a suffix added: my fedora build has `-inplace` appended
and I see short 4 char hashes in the upstream bindist (eg fedora33 build).
Grepping a bit didn't give me any real clues, what is going on...
## Steps to reproduce
`$ hadrian binary-dist-dir`
https://koji.fedoraproject.org/koji/taskinfo?taskID=104361497
https://koji.fedoraproject.org/koji/getfile?taskID=104361497&volume=DEFAULT&name=build.log&offset=-890000
## Expected behavior
No prefix?
## Environment
* GHC version used: 9.8.1-alpha1
Optional:
* Operating System: Fedora Linux
* System Architecture: x86_649.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23487debian 10 bindist depends on libzstd2023-07-20T16:09:44ZMatthew Pickeringdebian 10 bindist depends on libzstdSee https://gitlab.haskell.org/ghc/ghcup-ci/-/jobs/1545608
The debian 10 bindist should not depend on libzstd.See https://gitlab.haskell.org/ghc/ghcup-ci/-/jobs/1545608
The debian 10 bindist should not depend on libzstd.9.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/22982ghc bindist configure doesn't work on 9.2.6 Arm64 mac with any nonstandard co...2023-04-04T08:09:40ZCarter Schonwaldghc bindist configure doesn't work on 9.2.6 Arm64 mac with any nonstandard config. Or: configure ignores CC and always picks gcc, no mwatter what## Summary
i'd expect `> ./configure --prefix=/Users/carter/.ghc_install/ghc_9.2.6_hq --disable-ld-override CC=(which gcc-12) CPP=(which gcc-12)
`
to work, since i have Gcc-12 install on my mac. instead I get configure failures, or to m...## Summary
i'd expect `> ./configure --prefix=/Users/carter/.ghc_install/ghc_9.2.6_hq --disable-ld-override CC=(which gcc-12) CPP=(which gcc-12)
`
to work, since i have Gcc-12 install on my mac. instead I get configure failures, or to make things even more insane
`> ./configure --prefix=/Users/carter/.ghc_install/ghc_9.2.6_hq --disable-ld-override CC=(which gcc-12) `
doesn't fail, but when I look at the settings file which *should be generated from this*, i see `,("C compiler command", "gcc")
`
rather than the expected `/opt/homebrew/bin/gcc-12`
Configure step of a bindist *must* use CC, CPP, CXX etc, and *must* generate the settings file. It seems that it doesn't.
I believe this issue likely also is the culprit for problems i've had installing ghc 9.4.x versions too
heres links to example configure runs https://www.irccloud.com/pastebin/WhqTTd5p/
and associated config.log https://www.irccloud.com/pastebin/nHchjYDl/
do note that my tiny shell examples are using `fish shell`, but as you can see from the pastes, the substitutions work correctly there
* Operating System: OSX, ARM, but should be a problem on all other platforms. I just am more likely than most to swap my C compilers aroundBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/21974GHC 9.4.1 binary distribution wrapper installation broken on BSDs including m...2022-10-14T17:50:40ZBen GamariGHC 9.4.1 binary distribution wrapper installation broken on BSDs including macOSIt turns out that a seemingly harmless change made in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8763 broken installation of the wrapper scripts installed by the bindist Makefile. Specifically, changing `cp -RP` to `cp -P` broke...It turns out that a seemingly harmless change made in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8763 broken installation of the wrapper scripts installed by the bindist Makefile. Specifically, changing `cp -RP` to `cp -P` broke on BSDs, which differ subtly in semantics from `coreutils`'s `cp` when copying symbolic links. This wasn't caught by CI since the only BSD which we test is Darwin, where we use `coreutils` in our testing environment.9.4.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/21956Deb11 built against liffi8 but should be built against libffi72022-08-09T14:29:31ZMatthew PickeringDeb11 built against liffi8 but should be built against libffi7Henning Thielemann reports:
> I try
>
> https://downloads.haskell.org/ghc/9.4.1-rc1/ghc-9.4.0.20220721-x86_64-deb11-linux.tar.lz
>
> on Debian 11.
>
> $ /usr/local/ghc-9.4.0/bin/ghc --version
> /usr/local/ghc-9.4.0/lib/ghc-9.4.0.20...Henning Thielemann reports:
> I try
>
> https://downloads.haskell.org/ghc/9.4.1-rc1/ghc-9.4.0.20220721-x86_64-deb11-linux.tar.lz
>
> on Debian 11.
>
> $ /usr/local/ghc-9.4.0/bin/ghc --version
> /usr/local/ghc-9.4.0/lib/ghc-9.4.0.20220721/bin/ghc-9.4.0.20220721: error
> while loading shared libraries: libffi.so.8: cannot open shared object
> file: No such file or directory
>
>
> Debian 11 seems to support only libffi7:
>
> $ dpkg --list "*libffi*"
>
> ii libffi-dev:amd64 3.3-6 amd64 Foreign Function Interface library (development files)
> un libffi4-dev <keine> <keine> (keine Beschreibung vorhanden)
> ii libffi7:amd64 3.3-6 amd64 Foreign Function Interface library runtime
> ii libffi7:i386 3.3-6 i386 Foreign Function Interface library runtime
>
>
> I think this dependency is new and was not present in the Alpha releases.
>
>
>
> Also many directories have no read and cd permissions for 'other' users.9.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/21402Alpine bindists installation breaks if the prefix contains "xxx"2022-07-28T10:12:14ZsterniAlpine bindists installation breaks if the prefix contains "xxx"## Summary
When the Alpine bindists (tested with 8.10.2 and 9.2.2) are configured to have a `--prefix` containing `xxx` anywhere in the path, the installation will fail while trying to access paths that curiously contain 3 spaces instea...## Summary
When the Alpine bindists (tested with 8.10.2 and 9.2.2) are configured to have a `--prefix` containing `xxx` anywhere in the path, the installation will fail while trying to access paths that curiously contain 3 spaces instead of `xxx`.
This is because of the following snippet from its `Makefile` where `xxx` is used to temporarily sanitize three spaces:
```
PKG_CONFS = $(shell find "$(ActualLibsDir)/package.conf.d" -name '*.conf' | sed 's: :xxx:g')
update_package_db: install_bin install_lib
@echo "$(PKG_CONFS)"
@echo "Updating the package DB"
$(foreach p, $(PKG_CONFS),\
$(call patchpackageconf,$(shell echo $(notdir $p) | sed 's/-\([0-9]*[0-9]\.\)*conf//g'),$(shell echo "$p" | sed 's:xxx: :g'),$(docdir),$(shell mk/relpath.s
h "$(ActualLibsDir)" "$(docdir)")))
'$(WrapperBinsDir)/$(CrossCompilePrefix)ghc-pkg' recache
```
## Steps to reproduce
Use an Alpine bindist for either 8.10.2 or 9.2.2 (others likely also work) and select a prefix containing `xxx` for `configure`, then install.
## Expected behavior
The installation works normally. Having `xxx` in prefix is rare, but can happen for Nix since `x` is part of the alphabet used for Nix's base32 hashes.
## Environment
* GHC version used: 9.2.2, 8.10.2
Optional:
* Operating System: NixOS
* System Architecture: x86_64-linuxBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/207079.2.1 distributions missing profiling2023-04-03T20:48:22Zelaforge9.2.1 distributions missing profiling## Summary
It seems the OS X distribution (from https://downloads.haskell.org/~ghc/9.2.1/ghc-9.2.1-x86_64-apple-darwin.tar.xz) is missing the profiling libraries for base:
```
% ls /usr/local/lib/ghc-9.2.1/lib/x86_64-osx-ghc-9.2.1/base...## Summary
It seems the OS X distribution (from https://downloads.haskell.org/~ghc/9.2.1/ghc-9.2.1-x86_64-apple-darwin.tar.xz) is missing the profiling libraries for base:
```
% ls /usr/local/lib/ghc-9.2.1/lib/x86_64-osx-ghc-9.2.1/base-4.16.0.0/
Control/ GHC/ System/
Data/ Numeric/ Text/
Debug/ Numeric.dyn_hi Type/
Foreign/ Numeric.hi Unsafe/
Foreign.dyn_hi Prelude.dyn_hi include/
Foreign.hi Prelude.hi libHSbase-4.16.0.0.a
```
Compared to 9.0.1:
```
% ls /usr/local/lib/ghc-9.0.1/base-4.15.0.0/
Control/ Numeric.p_hi
Data/ Prelude.dyn_hi
Debug/ Prelude.hi
Foreign/ Prelude.p_hi
Foreign.dyn_hi System/
Foreign.hi Text/
Foreign.p_hi Type/
GHC/ Unsafe/
HSbase-4.15.0.0.o include/
HSbase-4.15.0.0.p_o libHSbase-4.15.0.0-ghc9.0.1.dylib*
Numeric/ libHSbase-4.15.0.0.a
Numeric.dyn_hi libHSbase-4.15.0.0_p.a
Numeric.hi
```
## Environment
* GHC version used: 9.2.1
Optional:
* Operating System: OS X
* System Architecture: intel9.2.2https://gitlab.haskell.org/ghc/ghc/-/issues/20208Binary distributions contain absolute symlink references2021-09-07T15:29:50ZBen GamariBinary distributions contain absolute symlink referencesThe Hadrian binary distributions produced for 9.2.1-rc1 (see https://gitlab.haskell.org/ghc/ghc/-/pipelines/39278) appear to still contain absolute symlink targets:
```
haskell-ci@Mini18-Beta> ls -lh ./lib/aarch64-osx-ghc-9.2.0.20210806...The Hadrian binary distributions produced for 9.2.1-rc1 (see https://gitlab.haskell.org/ghc/ghc/-/pipelines/39278) appear to still contain absolute symlink targets:
```
haskell-ci@Mini18-Beta> ls -lh ./lib/aarch64-osx-ghc-9.2.0.20210806/libHSrts-ghc9.2.0.20210806.dylib ~/tmp/ghc-9.2.0.20210806-aarch64-apple-darwin
lrwxr-xr-x 1 haskell-ci staff 144B Aug 6 13:10 ./lib/aarch64-osx-ghc-9.2.0.20210806/libHSrts-ghc9.2.0.20210806.dylib -> /private/var/lib/gitlab-runner/builds/dMxCCAEP/0/ghc/ghc/_build/stage1/lib/aarch64-osx-ghc-9.2.0.20210806/libHSrts-1.0.1-ghc9.2.0.20210806.dylib
```
This could either be more fallout from !6133 (see #20198) or it could be a regression introduced by the `Cabal` bump.9.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/20198hadrian install creates symlinks pointing to `_build` directory2021-10-12T06:43:31ZTeo Camarasuhadrian install creates symlinks pointing to `_build` directory## Summary
When using `hadrian/build install --prefix=<prefix>`, we end up with absolute symlinks pointing from unversioned executables to versioned ones. These symlinks are created in relation to the `_build` directory. This makes buil...## Summary
When using `hadrian/build install --prefix=<prefix>`, we end up with absolute symlinks pointing from unversioned executables to versioned ones. These symlinks are created in relation to the `_build` directory. This makes build outputs dependent on the existence of `_build`. So, they break when `install` copies these files elsewhere and the `_build` directory is later removed.
I encountered this in the context of building ghc with nix using a slightly modified version of https://gitlab.haskell.org/bgamari/ghcs-nix/-/blob/hadrian/hadrian.nix
This seems to be introduced by f481c1890066b4dac78d981ca680fb01cfff9a11
My guess is that the fix is to change https://gitlab.haskell.org/ghc/ghc/-/blob/f481c1890066b4dac78d981ca680fb01cfff9a11/hadrian/src/Rules/BinaryDist.hs#L166
such that we create a relative symlink rather than an absolute one.
## Steps to reproduce
1. Build ghc HEAD using hadrian
2. Install ghc somewhere using `hadrian/build install --prefix=<prefix>`
3. delete `_build`
4. try `<prefix>/bin/ghc --version`. You will get an error that looks like this:
```
bin/ghc: line 10: /nix/store/bq04dr93g6a87g4wkrxhpwcphpnan4cg-ghc-9.3.0/lib/ghc-9.3.20210802/bin/ghc: No such file or directory
```
Looking at the ghc exe with `ls -l` gives:
```
lrwxrwxrwx 3 teo teo 84 Jan 1 1970 ghc -> /build/ghc/_build/bindist/ghc-9.3.20210802-x86_64-unknown-linux/bin/ghc-9.3.20210802
```
## Expected behavior
`ghc --version` should run successfully
## Environment
* GHC version used: ghc-9.3.20210802
Optional:
* Operating System: Linux
* System Architecture: x86_64Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/19950macOS: Freshly installed GHC 8.10.5 linker reports undefined symbol `___darwi...2021-09-28T08:29:12ZAndreas AbelmacOS: Freshly installed GHC 8.10.5 linker reports undefined symbol `___darwin_check_fd_set_overflow`Just downloaded https://downloads.haskell.org/~ghc/8.10.5/ghc-8.10.5-x86_64-apple-darwin.tar.xz and installed it via `./configure && make install`. It does not seem to want to build executables:
```
$ cabal install alex
Resolving depend...Just downloaded https://downloads.haskell.org/~ghc/8.10.5/ghc-8.10.5-x86_64-apple-darwin.tar.xz and installed it via `./configure && make install`. It does not seem to want to build executables:
```
$ cabal install alex
Resolving dependencies...
Build profile: -w ghc-8.10.5 -O1
In order, the following will be built (use -v for more details):
- alex-3.2.6 (exe:alex) (requires build)
Configuring executable 'alex' for alex-3.2.6..
Preprocessing executable 'alex' for alex-3.2.6..
Building executable 'alex' for alex-3.2.6..
...
[22 of 22] Compiling Main ( src/Main.hs, dist/build/alex/alex-tmp/Main.o )
Linking dist/build/alex/alex ...
Undefined symbols for architecture x86_64:
"___darwin_check_fd_set_overflow", referenced from:
_awaitEvent in libHSrts.a(Select.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
`gcc' failed in phase `Linker'. (Exit code: 1)
cabal: Failed to build exe:alex from alex-3.2.6.
```
I didn't have this problem before, neither with 8.10.4 or 9.0.1.
This issue seems to be the same as closed issue #18760.
Shouldn't `./configure` check that I have a compatible infrastructure?
The written system requirements for the binary dist are:
(https://www.haskell.org/ghc/download_ghc_8_10_5.html#macosx_x86_64)
> This is a distribution for Mac OS X, 10.7 or later. The package requires the command line tools package of Xcode 4 or XCode 5 to be installed.
System information:
- macOS Mojave 10.14.6
```
$ xcodebuild -version
Xcode 11.3.1
Build version 11C504
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
```9.2.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/19846ghc-bignum version is not bumped2022-01-04T15:19:04ZOleg Grenrusghc-bignum version is not bumpedin GHC-9.0 nor GHC-9.2 branch, but it contains additions of new instances.
See my comment on https://gitlab.haskell.org/ghc/ghc/-/commit/882cc3638224674805e2b26e43cad853983575b5#note_352573
This is a release blocker for both GHC-9.0.2 ...in GHC-9.0 nor GHC-9.2 branch, but it contains additions of new instances.
See my comment on https://gitlab.haskell.org/ghc/ghc/-/commit/882cc3638224674805e2b26e43cad853983575b5#note_352573
This is a release blocker for both GHC-9.0.2 and GHC-9.2.1.9.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/197639.2 alpha2 and 8.10.5 fail to load ghci lib due to allocateWrite missing2021-10-14T13:51:44Zadam9.2 alpha2 and 8.10.5 fail to load ghci lib due to allocateWrite missingFails like:
```
ghc-stage2: <sanitised>/libraries/ghci/dist-install/build/HSghci-9.2.0.20210422.o: unknown symbol `allocateWrite'
ghc-stage2: Could not load Object Code <sanitised>/libraries/ghci/dist-install/build/HSghci-9.2.0.20210422...Fails like:
```
ghc-stage2: <sanitised>/libraries/ghci/dist-install/build/HSghci-9.2.0.20210422.o: unknown symbol `allocateWrite'
ghc-stage2: Could not load Object Code <sanitised>/libraries/ghci/dist-install/build/HSghci-9.2.0.20210422.o.
```
We build using make and crucially with `DYNAMIC_GHC_PROGRAMS=NO`. I suspect there's a missing export of `allocateWrite` in the RTS.8.10.6https://gitlab.haskell.org/ghc/ghc/-/issues/19751macOS: Installation, nix builds, and more2021-09-07T15:38:13ZMoritz AngermannmacOS: Installation, nix builds, and moreSince we build GHC now in reproducible nix-shells, and not with ad-hoc brew installs anymore, we may see nix-paths leak into the produced binary dists. This is quite unfortunate, but at the same time some what expected.
I've laid out on...Since we build GHC now in reproducible nix-shells, and not with ad-hoc brew installs anymore, we may see nix-paths leak into the produced binary dists. This is quite unfortunate, but at the same time some what expected.
I've laid out on IRC two options we effectively have:
(1) leak the impure dependencies we want into the nix-shell.
(2) ship the extra dependencies with GHC.
On top of that we still have issues with unsigned installes.
----
Dealing with unsigned ghc-cabal. This is rather easy to fix I believe, we just need to call `xattr -c -r .` from the `make install` target on darwin; or we go the long way with signing, which I'd rather we don't go into right now as our resources (especially on darwin) are stretched remarkably thin!
---
If we install a recent built from the 9.2 branch for x86_64 on darwin and look for references in the libraries we see:
```
find . -name "*.dylib" -type f -exec otool -L {} \; |grep -v "^\." |sort |uniq
/nix/store/dafajn07ybgi8mc95wd62pk1fcl6s46g-libiconv-50/lib/libiconv.dylib (compatibility version 7.0.0, current version 7.0.0)
/nix/store/wxx8sfsa5x1753r8d1x8dx2927qncwbw-ncurses-6.2/lib/libncursesw.6.dylib (compatibility version 6.0.0, current version 6.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
@rpath/libHSCabal-3.5.0.0-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSarray-0.5.4.0-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSbase-4.16.0.0-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSbinary-0.8.8.0-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSbytestring-0.11.1.0-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHScontainers-0.6.4.1-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSdeepseq-1.4.6.0-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSdirectory-1.3.6.1-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSexceptions-0.10.4-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSfilepath-1.4.2.1-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSghc-9.2.0.20210423-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSghc-bignum-1.0-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSghc-boot-9.2.0.20210423-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSghc-boot-th-9.2.0.20210423-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSghc-compact-0.1.0.0-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSghc-heap-9.2.0.20210423-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSghc-prim-0.8.0-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSghci-9.2.0.20210423-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHShaskeline-0.8.1.0-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHShpc-0.6.1.0-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSinteger-gmp-1.1-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSlibiserv-9.2.0.20210423-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSmtl-2.2.2-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSparsec-3.1.14.0-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSpretty-1.1.3.6-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSprocess-1.6.11.0-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSrts-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSrts_debug-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSrts_l-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSrts_thr-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSrts_thr_debug-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSrts_thr_l-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSstm-2.5.0.0-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHStemplate-haskell-2.18.0.0-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSterminfo-0.4.1.4-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHStext-1.2.4.2-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHStime-1.11.1.1-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHStransformers-0.5.6.2-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSunix-2.7.2.2-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libHSxhtml-3000.2.2.1-ghc9.2.0.20210423.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libffi.dylib (compatibility version 9.0.0, current version 9.0.0)
```
This looks fairly ok except for `curses` and `iconv`, we may not be able to "just" rewrite them with install_name_tool to the system shipped ones, as they might not match the ABI.
Trying to locate anything that contains /nix/store in them we find:
```
grep "/nix/store" -R .
Binary file ./lib/ghc-9.2.0.20210423/bin/ghc-iserv matches
./lib/ghc-9.2.0.20210423/package.conf.d/terminfo-0.4.1.4.conf: /nix/store/wxx8sfsa5x1753r8d1x8dx2927qncwbw-ncurses-6.2/lib
./lib/ghc-9.2.0.20210423/package.conf.d/terminfo-0.4.1.4.conf: /nix/store/wxx8sfsa5x1753r8d1x8dx2927qncwbw-ncurses-6.2/lib
Binary file ./lib/ghc-9.2.0.20210423/package.conf.d/package.cache matches
Binary file ./lib/ghc-9.2.0.20210423/rts/libHSrts_thr_debug-ghc9.2.0.20210423.dylib matches
Binary file ./lib/ghc-9.2.0.20210423/rts/libHSrts_thr-ghc9.2.0.20210423.dylib matches
Binary file ./lib/ghc-9.2.0.20210423/rts/libHSrts_debug-ghc9.2.0.20210423.dylib matches
Binary file ./lib/ghc-9.2.0.20210423/rts/libHSrts-ghc9.2.0.20210423.dylib matches
Binary file ./lib/ghc-9.2.0.20210423/rts/libHSrts_thr_debug.a matches
Binary file ./lib/ghc-9.2.0.20210423/rts/libHSrts_debug.a matches
Binary file ./lib/ghc-9.2.0.20210423/rts/libHSrts_l.a matches
Binary file ./lib/ghc-9.2.0.20210423/rts/libHSrts_l-ghc9.2.0.20210423.dylib matches
Binary file ./lib/ghc-9.2.0.20210423/rts/libHSrts_thr_l.a matches
Binary file ./lib/ghc-9.2.0.20210423/rts/libHSrts_thr.a matches
Binary file ./lib/ghc-9.2.0.20210423/rts/libHSrts.a matches
Binary file ./lib/ghc-9.2.0.20210423/rts/libHSrts_thr_l-ghc9.2.0.20210423.dylib matches
Binary file ./lib/ghc-9.2.0.20210423/haskeline-0.8.1.0/libHShaskeline-0.8.1.0-ghc9.2.0.20210423.dylib matches
Binary file ./lib/ghc-9.2.0.20210423/ghc-9.2.0.20210423/libHSghc-9.2.0.20210423-ghc9.2.0.20210423.dylib matches
Binary file ./lib/ghc-9.2.0.20210423/base-4.16.0.0/libHSbase-4.16.0.0-ghc9.2.0.20210423.dylib matches
Binary file ./lib/ghc-9.2.0.20210423/terminfo-0.4.1.4/libHSterminfo-0.4.1.4-ghc9.2.0.20210423.dylib matches
```
of course we see terminfo, which references curses, base references iconv, and ghc references curses again.
ghc-iserv references libiconv, and the rts seems to contain references to header file paths of libsystem.9.2.1Ben GamariCarter SchonwaldMoritz AngermannBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/19748missing read permission for package.cache2023-06-02T11:10:35ZLemmingmissing read permission for package.cache## Summary
When installing GHC from the Debian tarball, `package.cache` misses read permissions.
## Steps to reproduce
~~~
$ ll /usr/local/ghc-9.2.0.20210422/lib/ghc-9.2.0.20210422/package.conf.d/package.cache
-rw------- 1 root root 1...## Summary
When installing GHC from the Debian tarball, `package.cache` misses read permissions.
## Steps to reproduce
~~~
$ ll /usr/local/ghc-9.2.0.20210422/lib/ghc-9.2.0.20210422/package.conf.d/package.cache
-rw------- 1 root root 188641 23. Apr 16:56 /usr/local/ghc-9.2.0.20210422/lib/ghc-9.2.0.20210422/package.conf.d/package.cache
~~~
## Expected behavior
I can solve the problem with
~~~
$ sudo chmod a+r /usr/local/ghc-9.2.0.20210422/lib/ghc-9.2.0.20210422/package.conf.d/package.cache
~~~~
## Environment
Used archive:
https://downloads.haskell.org/ghc/9.2.1-alpha2/ghc-9.2.0.20210422-x86_64-deb10-linux.tar.xz9.2.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/197349.2.1-alpha2 fails to install on OS X2021-12-25T13:22:23ZEdward Kmett9.2.1-alpha2 fails to install on OS X## Summary
Attempting to install on a normal OSX machine fails.
## Steps to reproduce
Install:
In my case using
```
$ ghcup install ghc -u file:///Users/ekmett/ghc/ghc-9.2.0.20210422-x86_64-apple-darwin.tar.xz head
```
leads to
```...## Summary
Attempting to install on a normal OSX machine fails.
## Steps to reproduce
Install:
In my case using
```
$ ghcup install ghc -u file:///Users/ekmett/ghc/ghc-9.2.0.20210422-x86_64-apple-darwin.tar.xz head
```
leads to
```
[ ghc-make ] "/Users/ekmett/.ghcup/ghc/head/lib/ghc-9.2.0.20210422/bin/ghc-pkg" --force --global-package-db "/Users/ekmet...
a... dyld: Library not loaded: /nix/store/wxx8sfsa5x1753r8d1x8dx2927qncwbw-ncurses-6.2/lib/libncursesw.6.dylib
a...c-make ] Referenced from: /Users/ekmett/.ghcup/ghc/head/lib/ghc-9.2.0.20210422/terminfo-0.4.1.4/libHSterminfo-0.4.1...
[ ghc-make ] Reason: image not found
[ ghc-make ] make[1]: *** [install_packages] Abort trap: 6
a... make: *** [install] Error 2
```
I get the same error if I extract the distribution, `xattr -rc` and then `./configure` and `make install` as normal.
It appears that the distribution includes fixed path links to `nix-darwin` specific build paths.
## Expected behavior
Installation of ghc 9.2.1-alpha2.
## Environment
* GHC version used: 9.2.1-alpha2
Optional:
* Operating System: OSX
* System Architecture: Darwin9.2.1