Cabal on Mac OSX EL Capitan - forwarding DYLD_LIBRARY_PATH

tamarind code tamarindcode at
Mon Feb 1 13:30:18 UTC 2016

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.

On 27 January 2016 at 10:57, Herbert Valerio Riedel <hvriedel at>

> 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]:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list