Hi, Reposting my old question. Are there anyone with any ideas about a possible resolution to this without removing SIP on OSX please? Or is this silence telling me that Apple macs aren't very popular in the Haskell community ? https://github.com/commercialhaskell/stack/issues/1161#issuecomment-15847397... On 1 February 2016 at 13:30, tamarind code wrote:

Thanks for the response Herbert Valerio Riedel. Sorry I shouldn't have sued the word 'bug' here as this seems to be a result of something Apple did that breaks backward compatibility. I have just done a quick search and as you said it did seem to break a lot of other software including Posgresql and Oracle drivers and a whole bunch of others that are affected by this. So there is plenty of discussion around this.

Before I go any further I must say I am a newbie who doesn't even understand the fully details of the issue so sorry if I am saying something silly, But after a bit of googling I got the impression that some have found ways to get around the issue without having to disable SIP. They seem to remove the dependency on this path - if I understood this correctly.

I am posting a few links with the hope that they may be useful for people with more knowledge on this to figure our a similar solution if possible. Sorry if they solutions below don't apply to the issue we are talking about. As Apple is unlikely to do anything about it anytime soon, I do hope the Haskell community will find a better way to avoid this without messing with SIP.

https://groups.google.com/d/msg/dealii/NsniOXPvOyo/zHacLvk7DgAJ

https://github.com/oracle/node-oracledb/issues/149

https://blogs.oracle.com/taylor22/entry/sqlplus_and_dyld_library_path

On 27 January 2016 at 10:57, Herbert Valerio Riedel wrote:

...

On 2016-01-27 at 11:37:53 +0100, tamarind code wrote:

...

There was a discussion in github about stack (see link below) where the conclusion seems to be pointing towards a bug in Cabal on Mac OSX EL Capitan related to forwarding DYLD_LIBRARY_PATH

Is this really a bug *in Cabal*? Or is this rather a newly introduced OS limitation of El Capitan, which may even be in conflict with the POSIX specs. Quoting[1]:

...

Spawning children processes of processes restricted by System Integrity Protection, such as by launching a helper process in a bundle with NSTask or calling the exec(2) command, resets the Mach special ports of that child process. Any dynamic linker (dyld) environment variables, such as DYLD_LIBRARY_PATH, are purged when launching protected processes.

So OSX deliberately interferes with environment-variable inheritance. So what is Cabal even supposed to do here? This also seems like a rather radical change, which will have probably broken a lot of other software projects relying that DYLD_LIBRARY_PATH is inherited throughout process creations.

[1]: https://developer.apple.com/library/prerelease/mac/documentation/Security/Co...

For the record, there’s now a GHC ticket tracking this issue: https://ghc.haskell.org/trac/ghc/ticket/11617 As I wrote there, my gut says there’s a reason that Apple made DYLD_LIBRARY_PATH not forward, we shouldn’t try to work around it, we don’t need to work around it for standard usage patterns, and if a user does want to work around it, they should think twice about why. —gershom On February 7, 2016 at 4:26:14 PM, Carter Schonwald (carter.schonwald@gmail.com) wrote:

theres emphatically OS X support for haskell, by folks such as myself.

however, my current understanding is that the environment variable passing issue that arises here is an artifact of STACK doing subprocess invocation.

if you can show me a build that i can replicate the problem on a vanilla OS X that hits this issue, that would be appreciated

then, it becomes a question of how to "simulate"/"emulate" suitable environment variable inheritance on affected systems.

Or just make sure that the config for all user / root shells has the right env variables set, so any sub process will pick up the right paths :) (i can't tell if thats been explored or not in the affected threads, but since most OS X machines are effectively single user systems, thats not an ownerous work around :) )

On Sat, Feb 6, 2016 at 8:14 AM, tamarind code wrote:

...

Hi, Reposting my old question. Are there anyone with any ideas about a possible resolution to this without removing SIP on OSX please? Or is this silence telling me that Apple macs aren't very popular in the Haskell community ?

https://github.com/commercialhaskell/stack/issues/1161#issuecomment-15847397...

On 1 February 2016 at 13:30, tamarind code wrote:

...

Thanks for the response Herbert Valerio Riedel. Sorry I shouldn't have sued the word 'bug' here as this seems to be a result of something Apple did that breaks backward compatibility. I have just done a quick search and as you said it did seem to break a lot of other software including Posgresql and Oracle drivers and a whole bunch of others that are affected by this. So there is plenty of discussion around this.

Before I go any further I must say I am a newbie who doesn't even understand the fully details of the issue so sorry if I am saying something silly, But after a bit of googling I got the impression that some have found ways to get around the issue without having to disable SIP. They seem to remove the dependency on this path - if I understood this correctly.

I am posting a few links with the hope that they may be useful for people with more knowledge on this to figure our a similar solution if possible. Sorry if they solutions below don't apply to the issue we are talking about. As Apple is unlikely to do anything about it anytime soon, I do hope the Haskell community will find a better way to avoid this without messing with SIP.

https://groups.google.com/d/msg/dealii/NsniOXPvOyo/zHacLvk7DgAJ

https://github.com/oracle/node-oracledb/issues/149

https://blogs.oracle.com/taylor22/entry/sqlplus_and_dyld_library_path

On 27 January 2016 at 10:57, Herbert Valerio Riedel wrote:

...

On 2016-01-27 at 11:37:53 +0100, tamarind code wrote:

...

There was a discussion in github about stack (see link below) where the conclusion seems to be pointing towards a bug in Cabal on Mac OSX EL Capitan related to forwarding DYLD_LIBRARY_PATH

Is this really a bug *in Cabal*? Or is this rather a newly introduced OS limitation of El Capitan, which may even be in conflict with the POSIX specs. Quoting[1]:

...

Spawning children processes of processes restricted by System Integrity Protection, such as by launching a helper process in a bundle with NSTask or calling the exec(2) command, resets the Mach special ports of that child process. Any dynamic linker (dyld) environment variables, such as DYLD_LIBRARY_PATH, are purged when launching protected processes.

So OSX deliberately interferes with environment-variable inheritance. So what is Cabal even supposed to do here? This also seems like a rather radical change, which will have probably broken a lot of other software projects relying that DYLD_LIBRARY_PATH is inherited throughout process creations.

[1]: https://developer.apple.com/library/prerelease/mac/documentation/Security/Co...

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries