[ANNOUNCE] GHC 9.4.1-rc1 is now available

[George Colpitts]

+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/20220723/7dc19079/attachment.html>