[ANNOUNCE] GHC 9.4.1-rc1 is now available

newer
Re: [Haskell-cafe] [ANNOUNCE] GHC...

older
Compilation of Overloaded strings...

Ben Gamari

22 Jul 2022 22 Jul '22

9:05 a.m.

The GHC developers are happy to announce the availability of the first (and likely last) release candidate of GHC 9.4.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org]. This major release will include: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This provides informative profiles while interfering significantly less with GHC's aggressive optimisations, making it easier to understand the performance of programs which depend upon simplification.. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302] - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions. - Reintroduction of deep subsumption (which was previously dropped with the *simplified subsumption* change) as a language extension. - ... and much more. See the [release notes] for a full accounting. Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by our Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. We will be publishing a blog post describing the migration process to Hadrian in the coming weeks. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy testing, - Ben [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.4.1-rc1/ [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-ca... [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11... [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11... [release notes]: https://downloads.haskell.org/~ghc/9.4.1-rc1/docs/users_guide/9.4.1-notes.ht...

Attachments:

signature.asc (application/pgp-signature — 487 bytes)

Show replies by date

George Colpitts

22 Jul 22 Jul

1:43 p.m.

Hi Ben, I expected https://gitlab.haskell.org/ghc/ghc/-/issues/21506 (ghc-9.4.1-alpha1 does not install on macos: ghc-pkg-9.4.0-20220501 cannot be opened because the developer cannot be verified) to be fixed in rc1 but it is not. Are my expectations wrong? What is the ETA for fixing it? Thanks George On Fri, Jul 22, 2022 at 10:05 AM Ben Gamari wrote:

...

The GHC developers are happy to announce the availability of the first (and likely last) release candidate of GHC 9.4.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org].

This major release will include:

- A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This provides informative profiles while interfering significantly less with GHC's aggressive optimisations, making it easier to understand the performance of programs which depend upon simplification..

- A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families.

- An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing.

- Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs.

- Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`.

- Introduction of the `\cases` syntax from [GHC proposal 0302]

- A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO.

- Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects.

- A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support.

- Significant compile-time improvements to runtime and memory consumption.

- On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions.

- Reintroduction of deep subsumption (which was previously dropped with the *simplified subsumption* change) as a language extension.

- ... and much more. See the [release notes] for a full accounting.

Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by our Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. We will be publishing a blog post describing the migration process to Hadrian in the coming weeks.

We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.

As always, do give this release a try and open a [ticket] if you see anything amiss.

Happy testing,

- Ben

[downloads.haskell.org]: https://downloads.haskell.org/ghc/9.4.1-rc1/ [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-ca... [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11... [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11... [release notes]: https://downloads.haskell.org/~ghc/9.4.1-rc1/docs/users_guide/9.4.1-notes.ht...

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Ben Gamari

11:30 p.m.

George Colpitts writes:

...

Hi Ben,

I expected https://gitlab.haskell.org/ghc/ghc/-/issues/21506 (ghc-9.4.1-alpha1 does not install on macos: ghc-pkg-9.4.0-20220501 cannot be opened because the developer cannot be verified) to be fixed in rc1 but it is not. Are my expectations wrong? What is the ETA for fixing it?

Thanks for letting us know, George. The fix that we have [1] is present in 9.4.1-rc1. If that commit doesn't resolve the issue then there is something that we don't understand. Does `/usr/bin/xattr` exist? Running `xattr -rc` manually on the binary distribution allow you to run the compiler? Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/commit/641972d65b476aac11424bde6c3bcfda...

George Colpitts

23 Jul 23 Jul

7:20 a.m.

Hi Ben /ust/bin/xattr exists on my machine. Running "xattr -rc ." manually does not fix the bug as noted at the start of 21506. It was sufficient in the past but no longer fixes this error. As noted farther down in 21506 the workaround given in #17418 no longer works. It did not work in 9.2.2 either. The current workaround is similar to what Kazu explained in https://twitter.com/kazu_yamamoto/status/1500643489985761282 sudo xattr -rc . sudo spctl --global-disable ./configure sudo make install sudo spctl --global-enable It seems there are files created during sudo make install that have an issue as xattr -rc . was never run on them. Perhaps this is related to using Hadrian. Is it possible that the fix that was made was never tested? Thanks George On Sat, Jul 23, 2022 at 12:30 AM Ben Gamari wrote:

...

George Colpitts writes:

...
Hi Ben,

I expected https://gitlab.haskell.org/ghc/ghc/-/issues/21506 (ghc-9.4.1-alpha1 does not install on macos: ghc-pkg-9.4.0-20220501 cannot be opened because the developer cannot be verified) to be fixed in rc1 but it is not. Are my expectations wrong? What is the ETA for fixing it?

Thanks for letting us know, George. The fix that we have [1] is present in 9.4.1-rc1. If that commit doesn't resolve the issue then there is something that we don't understand. Does `/usr/bin/xattr` exist? Running `xattr -rc` manually on the binary distribution allow you to run the compiler?

Cheers,

- Ben

[1] https://gitlab.haskell.org/ghc/ghc/-/commit/641972d65b476aac11424bde6c3bcfda...

Ben Gamari

9:03 a.m.

George Colpitts writes:

...

Hi Ben

/ust/bin/xattr exists on my machine. Running "xattr -rc ." manually does not fix the bug as noted at the start of 21506. It was sufficient in the past but no longer fixes this error. As noted farther down in 21506

the workaround given in #17418 no longer works. It did not work in 9.2.2 either. The current workaround is similar to what Kazu explained in https://twitter.com/kazu_yamamoto/status/1500643489985761282

sudo xattr -rc .

sudo spctl --global-disable

./configure

sudo make install

sudo spctl --global-enable

It seems there are files created during sudo make install that have an issue as xattr -rc . was never run on them. Perhaps this is related to using Hadrian. Is it possible that the fix that was made was never tested?

I tested the change both manually and via CI on the hardware that I have access to; in both cases installing the binary distribution resulted in a functional compiler. However, given how the effects of SIP are essentially undocumented, it is very hard to know what variables may be at play here. Running spctl --status on the machine on which I tested claims: > spctl --status objc[48908]: Class SPExecutionPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapper is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapperPolicyResult is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapperPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPLog is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class MIS is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPExecutionHistoryItem is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPExecutionPolicyItem is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPDeveloperPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class GKScanResult is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. assessments enabled Which to me suggests that SIP (which, I imagine, is responsible for #21506) is enabled. However, the lack of comprehensive documentation here makes it very hard to say with certainty what might differ between your machine and mine. Without more information I don't know how to proceed here. Perhaps someone (Moritz or Simon, perhaps) with more familiarity with macOS has some insight? Thanks for your help in testing, George! Cheers, - Ben

George Colpitts

10:51 a.m.

+Kazu Yamamoto Hi Ben My 2 machines also have: $ spctl --status assessments enabled I've duplicated the issue on both of my machines. It would be good to know if anybody else is seeing it. Kazu, I know you have seen this in the past. Do you get the same error installing rc1? When I run sudo make install I get a popup that says: *“libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib” cannot be opened because the developer cannot be verified.* When I cancel out of that I get another popup with the same error. When I hit cancel on that the script ends with the output: # We finally replace the original file. mv '/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d/process-1.6.14.0.conf.copy.copy' '/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d/process-1.6.14.0.conf' '/usr/local/lib/ghc-9.4.0.20220721/bin/ghc-pkg' --global-package-db "/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d" recache dyld[32239]: Library not loaded: '@rpath/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' Referenced from: '/usr/local/lib/ghc-9.4.0.20220721/bin/ghc-pkg-9.4.0.20220721' Reason: tried:* '/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (code signature in <CA45AED4-4028-3B3F-9AA6-91EDE1078A7E> '/usr/local/lib/ghc-9.4.0.20220721/lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' not valid for use in process: library load disallowed by system policy), '$ORIGIN/../../../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file), '/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (code signature in <CA45AED4-4028-3B3F-9AA6-91EDE1078A7E> '/usr/local/lib/ghc-9.4.0.20220721/lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' not valid for use in process: library load disallowed by system policy),* '$ORIGIN/../../../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file), '/usr/local/lib/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file), '/usr/lib/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file) make: *** [update_package_db] Abort trap: 6 gcolpitts@macMini-2018 ghc-9.4.0.20220721-x86_64-apple-darwin % Hope this helps. Speculations: /usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib is created after xattr -rc . was run so it doesn't have the necessary attributes. Is it possible that ghc developers and/or the test machines have this file on another of the paths in the error message and that is why it works for them? I hope I didn't offend you by asking if the fix had been tested; I assume it had been but I thought it was important to rule that out. More than happy to test. I really appreciate all the work you and others have put into GHC ! Cheers George On Sat, Jul 23, 2022 at 10:03 AM Ben Gamari wrote:

...

George Colpitts writes:

...
Hi Ben

/ust/bin/xattr exists on my machine. Running "xattr -rc ." manually does not fix the bug as noted at the start of 21506. It was sufficient in the past but no longer fixes this error. As noted farther down in 21506

the workaround given in #17418 no longer works. It did not work in 9.2.2 either. The current workaround is similar to what Kazu explained in https://twitter.com/kazu_yamamoto/status/1500643489985761282

sudo xattr -rc .

sudo spctl --global-disable

./configure

sudo make install

sudo spctl --global-enable

It seems there are files created during sudo make install that have an issue as xattr -rc . was never run on them. Perhaps this is related to using Hadrian. Is it possible that the fix that was made was never tested?

I tested the change both manually and via CI on the hardware that I have access to; in both cases installing the binary distribution resulted in a functional compiler. However, given how the effects of SIP are essentially undocumented, it is very hard to know what variables may be at play here. Running spctl --status on the machine on which I tested claims:

> spctl --status objc[48908]: Class SPExecutionPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapper is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapperPolicyResult is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapperPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPLog is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class MIS is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPExecutionHistoryItem is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPExecutionPolicyItem is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPDeveloperPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class GKScanResult is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. assessments enabled

Which to me suggests that SIP (which, I imagine, is responsible for #21506) is enabled. However, the lack of comprehensive documentation here makes it very hard to say with certainty what might differ between your machine and mine. Without more information I don't know how to proceed here. Perhaps someone (Moritz or Simon, perhaps) with more familiarity with macOS has some insight?

Thanks for your help in testing, George!

Cheers,

- Ben

George Colpitts

24 Jul 24 Jul

7:43 a.m.

+ address that hopefully doesn't bounce for Moritz On Sat, Jul 23, 2022 at 11:51 AM George Colpitts wrote:

...

+Kazu Yamamoto

Hi Ben

My 2 machines also have:

$ spctl --status assessments enabled

I've duplicated the issue on both of my machines. It would be good to know if anybody else is seeing it. Kazu, I know you have seen this in the past. Do you get the same error installing rc1? When I run sudo make install I get a popup that says:

*“libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib” cannot be opened because the developer cannot be verified.*

When I cancel out of that I get another popup with the same error. When I hit cancel on that the script ends with the output:

# We finally replace the original file. mv '/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d/process-1.6.14.0.conf.copy.copy' '/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d/process-1.6.14.0.conf' '/usr/local/lib/ghc-9.4.0.20220721/bin/ghc-pkg' --global-package-db "/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d" recache dyld[32239]: Library not loaded: '@rpath/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' Referenced from: '/usr/local/lib/ghc-9.4.0.20220721/bin/ghc-pkg-9.4.0.20220721' Reason: tried:* '/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (code signature in <CA45AED4-4028-3B3F-9AA6-91EDE1078A7E> '/usr/local/lib/ghc-9.4.0.20220721/lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' not valid for use in process: library load disallowed by system policy), '$ORIGIN/../../../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file), '/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (code signature in <CA45AED4-4028-3B3F-9AA6-91EDE1078A7E> '/usr/local/lib/ghc-9.4.0.20220721/lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' not valid for use in process: library load disallowed by system policy),* '$ORIGIN/../../../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file), '/usr/local/lib/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file), '/usr/lib/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file) make: *** [update_package_db] Abort trap: 6 gcolpitts@macMini-2018 ghc-9.4.0.20220721-x86_64-apple-darwin %

Hope this helps.

Speculations:

/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib is created after xattr -rc . was run so it doesn't have the necessary attributes. Is it possible that ghc developers and/or the test machines have this file on another of the paths in the error message and that is why it works for them?

I hope I didn't offend you by asking if the fix had been tested; I assume it had been but I thought it was important to rule that out.

More than happy to test. I really appreciate all the work you and others have put into GHC !

Cheers George

On Sat, Jul 23, 2022 at 10:03 AM Ben Gamari wrote:

...
George Colpitts writes:

...
Hi Ben

/ust/bin/xattr exists on my machine. Running "xattr -rc ." manually does not fix the bug as noted at the start of 21506. It was sufficient in the past but no longer fixes this error. As noted farther down in 21506

the workaround given in #17418 no longer works. It did not work in 9.2.2 either. The current workaround is similar to what Kazu explained in https://twitter.com/kazu_yamamoto/status/1500643489985761282

sudo xattr -rc .

sudo spctl --global-disable

./configure

sudo make install

sudo spctl --global-enable

It seems there are files created during sudo make install that have an issue as xattr -rc . was never run on them. Perhaps this is related to using Hadrian. Is it possible that the fix that was made was never tested?

I tested the change both manually and via CI on the hardware that I have access to; in both cases installing the binary distribution resulted in a functional compiler. However, given how the effects of SIP are essentially undocumented, it is very hard to know what variables may be at play here. Running spctl --status on the machine on which I tested claims:

> spctl --status objc[48908]: Class SPExecutionPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapper is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapperPolicyResult is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapperPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPLog is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class MIS is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPExecutionHistoryItem is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPExecutionPolicyItem is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPDeveloperPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class GKScanResult is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. assessments enabled

Which to me suggests that SIP (which, I imagine, is responsible for #21506) is enabled. However, the lack of comprehensive documentation here makes it very hard to say with certainty what might differ between your machine and mine. Without more information I don't know how to proceed here. Perhaps someone (Moritz or Simon, perhaps) with more familiarity with macOS has some insight?

Thanks for your help in testing, George!

Cheers,

- Ben

Ben Gamari

10:33 a.m.

George Colpitts writes:

...

+Kazu Yamamoto

Hi Ben

My 2 machines also have:

$ spctl --status assessments enabled

Hmm, interesting. Then I am truly perplexed.

...

Speculations:

/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib is created after xattr -rc . was run so it doesn't have the necessary attributes. Is it possible that ghc developers and/or the test machines have this file on another of the paths in the error message and that is why it works for them?

I'm not sure where this would be but at this point anything is possible. What happens if you try to install to do something like (in the extracted binary distribution), $ ./configure --prefix=`pwd`/tmp $ make install # this will fail $ xattr -rc . $ make install # perhaps this will finish successfully? # tmp/bin/ghc --version # GHC should be usable

...

I hope I didn't offend you by asking if the fix had been tested; I assume it had been but I thought it was important to rule that out.

Not to worry; it's a very reasonable question to ask given the circumstances.

...

More than happy to test. I really appreciate all the work you and others have put into GHC !

George Colpitts

12:58 p.m.

New subject: success on a slightly modified version of your suggestion for 21506

Hi Ben Thanks for the quick responses particularly on the weekend before your vacation. you wrote: What happens if you try to install to do something like (in the extracted binary distribution), $ ./configure --prefix=`pwd`/tmp $ make install # this will fail $ xattr -rc . $ make install # perhaps this will finish successfully? # tmp/bin/ghc --version # GHC should be usable success on both my machines using a slightly modified version of your suggestion above for 21506: ./configure --prefix=`pwd`/tmp # specifying ./tmp seems to be critical xattr -rc . # seems to be necessary also sudo make install # seems to works , output ends with "recache" ./tmp/bin/ghc --version # success , although admittedly the smallest smoke test possible You wrote:

...

Ultimately I think we may just need to bite the bullet and start properly notarising/codesigning releases (resolving #17418). At this point we have spent more time trying to avoid the notarisation requirement than it would likely take to satisfy it. Unfortunately, this will require that I find an Apple device somewhere which may take a few weeks. I'm afraid I am on holiday next week but I would quite grateful if we could arrange for a chat after I return such that we can debug this in realtime. Sure, we can chat when you return from your vacation. Not sure if it is worth trying to fix the release on the basis of what I write above. My opinion is: it is if we can get reports of at least one other person having this issue. I am fine with not doing this for 9.4.1 I agree that we should raise the priority of "notarising/codesigning releases (resolving #17418)". My opinion is that it is not worth delaying 9.4.1 for this. Have a great vacation. Cheers George On Sun, Jul 24, 2022 at 11:33 AM Ben Gamari wrote:

...

George Colpitts writes:

...
+Kazu Yamamoto

Hi Ben

My 2 machines also have:

$ spctl --status assessments enabled

Hmm, interesting. Then I am truly perplexed.

...
Speculations:

/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib

...
is created after xattr -rc . was run so it doesn't have the necessary attributes. Is it possible that ghc developers and/or the test machines have this file on another of the paths in the error message and that is why it works for them?

I'm not sure where this would be but at this point anything is possible. What happens if you try to install to do something like (in the extracted binary distribution),

$ ./configure --prefix=`pwd`/tmp $ make install # this will fail $ xattr -rc . $ make install # perhaps this will finish successfully? # tmp/bin/ghc --version # GHC should be usable

...
I hope I didn't offend you by asking if the fix had been tested; I assume it had been but I thought it was important to rule that out.

Not to worry; it's a very reasonable question to ask given the circumstances.

...
More than happy to test. I really appreciate all the work you and others have put into GHC !

Ultimately I think we may just need to bite the bullet and start properly notarising/codesigning releases (resolving #17418). At this point we have spent more time trying to avoid the notarisation requirement than it would likely take to satisfy it. Unfortunately, this will require that I find an Apple device somewhere which may take a few weeks.

I'm afraid I am on holiday next week but I would quite grateful if we could arrange for a chat after I return such that we can debug this in realtime.

Cheers,

- Ben

Carter Schonwald

27 Jul 27 Jul

9:25 a.m.

New subject: success on a slightly modified version of your suggestion for 21506

that matches my experience, namely that i've successfully installed ghc 9.2.2 on osx 12.4 aka monterey a few times On Sun, Jul 24, 2022 at 12:59 PM George Colpitts wrote:

...

Hi Ben

Thanks for the quick responses particularly on the weekend before your vacation.

you wrote:

What happens if you try to install to do something like (in the extracted binary distribution),

$ ./configure --prefix=`pwd`/tmp $ make install # this will fail $ xattr -rc . $ make install # perhaps this will finish successfully? # tmp/bin/ghc --version # GHC should be usable

success on both my machines using a slightly modified version of your suggestion above for 21506:

./configure --prefix=`pwd`/tmp # specifying ./tmp seems to be critical

xattr -rc . # seems to be necessary also

sudo make install # seems to works , output ends with "recache"

./tmp/bin/ghc --version # success , although admittedly the smallest smoke test possible

You wrote:

...
Ultimately I think we may just need to bite the bullet and start properly notarising/codesigning releases (resolving #17418). At this point we have spent more time trying to avoid the notarisation requirement than it would likely take to satisfy it. Unfortunately, this will require that I find an Apple device somewhere which may take a few weeks.

I'm afraid I am on holiday next week but I would quite grateful if we could arrange for a chat after I return such that we can debug this in realtime.

Sure, we can chat when you return from your vacation.

Not sure if it is worth trying to fix the release on the basis of what I write above. My opinion is: it is if we can get reports of at least one other person having this issue. I am fine with not doing this for 9.4.1

I agree that we should raise the priority of "notarising/codesigning releases (resolving #17418)". My opinion is that it is not worth delaying 9.4.1 for this.

Have a great vacation.

Cheers George

On Sun, Jul 24, 2022 at 11:33 AM Ben Gamari wrote:

...
George Colpitts writes:

...
+Kazu Yamamoto

Hi Ben

My 2 machines also have:

$ spctl --status assessments enabled

Hmm, interesting. Then I am truly perplexed.

...
Speculations:

/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib

...
is created after xattr -rc . was run so it doesn't have the necessary attributes. Is it possible that ghc developers and/or the test machines have this file on another of the paths in the error message and that is why it works for them?

I'm not sure where this would be but at this point anything is possible. What happens if you try to install to do something like (in the extracted binary distribution),

$ ./configure --prefix=`pwd`/tmp $ make install # this will fail $ xattr -rc . $ make install # perhaps this will finish successfully? # tmp/bin/ghc --version # GHC should be usable

...
I hope I didn't offend you by asking if the fix had been tested; I assume it had been but I thought it was important to rule that out.

Not to worry; it's a very reasonable question to ask given the circumstances.

...
More than happy to test. I really appreciate all the work you and others have put into GHC !

Ultimately I think we may just need to bite the bullet and start properly notarising/codesigning releases (resolving #17418). At this point we have spent more time trying to avoid the notarisation requirement than it would likely take to satisfy it. Unfortunately, this will require that I find an Apple device somewhere which may take a few weeks.

I'm afraid I am on holiday next week but I would quite grateful if we could arrange for a chat after I return such that we can debug this in realtime.

Cheers,

- Ben

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Kazu Yamamoto

25 Jul 25 Jul

12:23 a.m.

Hi George,

...

I've duplicated the issue on both of my machines. It would be good to know if anybody else is seeing it. Kazu, I know you have seen this in the past. Do you get the same error installing rc1? When I run sudo make install I get a popup that says:

I had no problem on 9.4.1-rc1. "xattr -rc ." and "make install" worked perfectly. macOS Monterey v12.4 Xcode 13.4.1 --Kazu

1028

Age (days ago)

1033

Last active (days ago)

List overview

Download

10 comments

4 participants

participants (4)

Ben Gamari
Carter Schonwald
George Colpitts
Kazu Yamamoto

[ANNOUNCE] GHC 9.4.1-rc1 is now available

tags

participants (4)