Cabal on Mac OSX EL Capitan - forwarding DYLD_LIBRARY_PATH

[Gershom B]

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 at 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-158473975  
> >
> > 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/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
> >
> >
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>