New release of GHC 7.8 to support OS X El Capitan
Hi, first some background: there is an issue with having Haskell on the next OS X “El Capitan”: [1] caused by security updates in the operating system. The cause is too old `unix` package, the same issue as in [2] Could someone verify that my understanding of the issue is correct, i.e. how Cabal-the-tool and Cabal-the-library interoperate. For me it seems, that one of the easiest ways to fix the issue (for the users), is to have a new release in 7.8 branch, with updated `unix` dependency. Or is it there too might hassle to be possible? Related issues: [3] [4] [1] https://github.com/haskell/cabal/issues/2653 https://github.com/haskell/cabal/issues/2653 [2] https://github.com/haskell/unix/pull/18 https://github.com/haskell/unix/pull/18 [3] https://github.com/commercialhaskell/stack/issues/563 https://github.com/commercialhaskell/stack/issues/563 [4] https://github.com/ghcformacosx/ghc-dot-app/issues/39#issuecomment-122088535 https://github.com/ghcformacosx/ghc-dot-app/issues/39#issuecomment-122088535 Greetings, Oleg P.S. hopefully Windows 10 doesn’t pose similar surprises.
Oleg Grenrus
Hi,
first some background: there is an issue with having Haskell on the next OS X “El Capitan”: [1] caused by security updates in the operating system. The cause is too old `unix` package, the same issue as in [2]
I would like to understand the root-cause of the issue. It seems that OS X will now raise EPERM instead of EACCES when certain files are accessed. That being said, it's not at all clear to me which system call is failing or why. Could someone familiar with El Capitan describe what exactly is going on here?
Could someone verify that my understanding of the issue is correct, i.e. how Cabal-the-tool and Cabal-the-library interoperate.
For me it seems, that one of the easiest ways to fix the issue (for the users), is to have a new release in 7.8 branch, with updated `unix` dependency. Or is it there too might hassle to be possible?
I will bring this up in next week's GHC meeting. Cheers, - Ben
On Sat, Jul 18, 2015 at 7:39 AM, Ben Gamari
I would like to understand the root-cause of the issue. It seems that OS X will now raise EPERM instead of EACCES when certain files are accessed. That being said, it's not at all clear to me which system call is failing or why. Could someone familiar with El Capitan describe what exactly is going on here?
The trace showed access("/usr/bin/ar", 2) => -1/EPERM (instead of -1/EACCES). http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature... appears relevant. Sounds to me like they automatically set a bunch of stuff immutable (chflags(1) schg flag; also see chflags(2), the underlying syscall) and bump the (equivalent of) securelevel so it can't be altered even by root after system boot. (Sadly, Apple did not bother to update the manpages to reflect launchd.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
Oleg Grenrus
Hi, first some background: there is an issue with having Haskell on the next OS X “El Capitan”: [1] caused by security updates in the operating system. The cause is too old `unix` package, the same issue as in [2]
I would like to understand the root-cause of the issue. It seems that OS X will now raise EPERM instead of EACCES when certain files are accessed. That being said, it's not at all clear to me which system call is failing or why. Could someone familiar with El Capitan describe what exactly is going on here?
Could someone verify that my understanding of the issue is correct, i.e. how Cabal-the-tool and Cabal-the-library interoperate.
For me it seems, that one of the easiest ways to fix the issue (for the users), is to have a new release in 7.8 branch, with updated `unix` dependency. Or is it there too might hassle to be possible?
I will bring this up in next week's GHC meeting. Cheers, - Ben
participants (4)
-
Ben Gamari -
Ben Gamari -
Brandon Allbery -
Oleg Grenrus