[ncl-install] Mac OS X 10.11 Incompatability

[Mary Haley]

Hi Kyle,

We try to remove as many of these shared library dependencies as possible,
and we've been able to get by with this situation with previous versions of
MacOS.

It doesn't surprise me that Apple has changed things up a bit, and
unfortunately, I don't have a 10.11 system to test on yet.  I have to be
careful about upgrading right away because this usually breaks my ability
to run VPN from home, which is critical for work.

I'm going to see if it's safe for me to upgrade to 10.11, and then I'll
give the NCL build a try.

I do appreciate you offering to be a guinea pig.  Have you actually tried
building NCL from source code?

--Mary


On Mon, Dec 14, 2015 at 9:37 AM, Kyle Griffin <ksgriffin2 at wisc.edu> wrote:

> Hi all,
>
> I wanted to highlight the result of a bit of research I've had to do after
> upgrading a Mac from 10.9 to 10.11 - specifically, that DYLD_LIBRARY_PATH
> and DYLD_FALLBACK_LIBRARY_PATH are no longer supported by default in OS X.
> While they can be set, this setting is not recognized in any automated
> (cron) calls to scripts. Here's on example output, where I print the
> contents of both environmental variables before attempting to run an NCL
> script. One environmental variable is set in .profile (manually sourced at
> start of the script) and one is set within the script itself. Both are
> ignored.
>
> /opt/local/lib/gcc49:/opt/local/lib/gcc
>
> /opt/local/lib/gcc49:/opt/local/lib/gcc
>
> dyld: Library not loaded: /usr/local/lib/libquadmath.0.dylib
>
>   Referenced from: /Users/ksgriffin2/ncl6.3.0.1010/bin/ncl
>
>   Reason: image not found
>
> The dyld:... error was originally missing libgfortran.3.dylib, but I
> manually created a link in /usr/local/lib to the version in
> /opt/local/lib/gcc49 try and tackle this problem. It appears that linking
> libgfortran.3.dylib, libquadmath.0.dylib, and libgomp.1.dylib does the
> trick to allow NCL to function as a workaround, but could be problematic
> long-term I would guess? The binary in use here is the Mac 10.10/gcc4.9.2
> binary.
>
> Apple now claims that any software relying on this should, essentially,
> not rely on these techniques any more or place them all in /usr/local/ (I'm
> using MacPorts, putting things /opt/local/) [see under last heading on the
> page]:
>
> https://developer.apple.com/library/mac/documentation/Security/Conceptual/System_Integrity_Protection_Guide/FileSystemProtections/FileSystemProtections.html#//apple_ref/doc/uid/TP40016462-CH2-DontLinkElementID_2
>
> This can, in theory, be fixed by accessing the system recovery and
> disabling the new "System Integrity Protection" feature that eliminates
> these issues, but I feel that is not an appropriate fix for this problem.
> For testing purposes, the simple process of disabling SIP is presented at
> the bottom of this article:
> http://www.macworld.com/article/2986118/security/how-to-modify-system-integrity-protection-in-el-capitan.html
>
> I should note the NCL appears to work fine from the command line, although
> I have to test it in depth.
>
> So it appears going forward that significant changes may need to be made
> to the NCL binaries for OS X in order for them to be functional at all.
> I'll be happy to serve as a guinea pig for fixes if a 10.11 system isn't
> available for testing...
>
>
> Kyle
> ----------------------------------------
> Kyle S. Griffin
> Department of Atmospheric and Oceanic Sciences
> University of Wisconsin - Madison
> Room 1407
> 1225 W Dayton St, Madison, WI 53706
> Email: ksgriffin2 at wisc.edu
>
> _______________________________________________
> ncl-install mailing list
> List instructions, subscriber options, unsubscribe:
> http://mailman.ucar.edu/mailman/listinfo/ncl-install
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/ncl-install/attachments/20151216/d679fd37/attachment-0001.html