+Kazu Yamamoto <k...@iij.ad.jp> 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 <b...@well-typed.com> wrote: > George Colpitts <george.colpi...@gmail.com> 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 </ghc/ghc/-/issues/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 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
