Cabal on Mac OSX EL Capitan - forwarding DYLD_LIBRARY_PATH

[Carter Schonwald]

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 at 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 ?
>
> https://github.com/commercialhaskell/stack/issues/1161#issuecomment-158473975
>
> On 1 February 2016 at 13:30, tamarind code <tamarindcode at 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
>>
>>
>> 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 <hvriedel at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160207/4875ae29/attachment.html>