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 <tamarindcode@gmail.com> 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 ?

On 1 February 2016 at 13:30, tamarind code <tamarindcode@gmail.com> 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


On 27 January 2016 at 10:57, Herbert Valerio Riedel <hvriedel@gmail.com> 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/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html#//apple_ref/doc/uid/TP40016462-CH3-SW1



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