Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available
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 signature.asc Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available
+ 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 > '/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 > '/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
Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available
+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 '/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 '/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 >
Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available
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 signature.asc Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available
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/641972d65b476aac11424bde6c3bcfda1c65aef5 > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available
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/641972d65b476aac11424bde6c3bcfda1c65aef5 signature.asc Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available
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-cases.rst > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > [bootstrap script]: > https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md > [Hadrian]: > https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian > [release notes]: > https://downloads.haskell.org/~ghc/9.4.1-rc1/docs/users_guide/9.4.1-notes.html > > ___ > ghc-devs mailing list > ghc-d...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
