+ address that hopefully doesn't bounce for Moritz On Sat, Jul 23, 2022 at 11:51 AM George Colpitts <george.colpi...@gmail.com> wrote:
> +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
