[ANNOUNCE] GHC 9.4.1-rc1 is now available

[George Colpitts]

+ address that hopefully doesn't bounce for Moritz

On Sat, Jul 23, 2022 at 11:51 AM George Colpitts <george.colpitts at gmail.com>
wrote:

> +Kazu Yamamoto <kazu at 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 at 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 <ben at well-typed.com> wrote:
>
>> George Colpitts <george.colpitts at 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20220724/4921b6f1/attachment.html>