Wednesday, July 29, 2020

Upgrade to MacOS 10.15.6 Catalina, Even More Bookkeeping Notes


When trying to install SAC, the Seismic Analysis Code, in MacOS 10.15.6 Catalina, I encountered some problems.  The MacOS upgrade fences off a number of legacy libraries and tools into the Relocated Items folder on the Desktop.  If something stopped working after the upgrade, I discovered that some essential file had been "relocated" to a place on my disk where the application or compiler could not find it.  For SAC, the executable could not find X11 runtime libraries for plotting.  Rather than re-request the software package from IRIS, I decided to recompile the application from the sac-101.6a-source.tar file that I had thankfully never deleted from my Utilities folder.  It is the same version of SAC that I have had from 2018, but I desired a clean (or cleaner) install.  

The SAC compilation is guided by the file Readme.buildsac within the sac-101.6a tarfile, a file unchanged from 2013, but two hurdles were not anticipated in this file.  First, the *.h header files for compilation are placed by Catalina in an obscure place, 

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include

which I had placed into my CPATH environmental variable, and 

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib

which I had placed into my LIBRARY_PATH environmental variable.  The compilation later halted when it could not find the X11 libraries.  The X11 libraries were actually sitting at several locations in my computer, but not where the  SAC Makefile looked for them.  Many software packages install their own versions of X11.  Rather that setting up some Rube-Goldberg linkages that could be broken later inadvertently, I decided to re-install the X11 libraries from scratch by downloading XQuartz, even though I had the latest version already installed, and I could already use XQuartz to open and execute command lines within X-windows.  This gambit succeeded, and the SAC makefile could advance beyond its loading of the X11 libraries.

There was one more Red Sea to part before I could reach the promised land of SAC functionality.  An obscure command within a header file crashed the makefile. The error was

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/AvailabilityInternal.h:33:18: error: missing binary operator before token "("

 The offending passage looked like this:

# if __has_include (<AvailabilityInternalPrivate.h>) # include <AvailabilityInternalPrivate.h> # endif

This code snippet looks for an auxiliary header file, and inserts it, if it can find it. Easy, right? Not easy. Some Google-sleuthing on the command "__has_include" revealed that not all versions of the gcc compiler have this command in their toolbox. My SAC makefile was crashing on not finding "__has_include"! The solution was to wrap the existing code with another IF statement:

#if defined __has_include # if __has_include (< AvailabilityInternalPrivate.h >) # include < AvailabilityInternalPrivate.h > # endif #endif

This way the Apple SDK checks to see if the C-preprocessor command actually exists before it tries to use it. Thankfully, my SDK does not have AvailabilityInternalPrivate.h, so I am not missing it.

I had to make this correction twice, in SDK files that could only be edited by root.


Monday, July 20, 2020

Upgrade to MacOS 10.15.6 Catalina, More Bookkeeping Notes

./configure --prefix=/opt/sac

On MacOS Catalina 10.15.6, with Xcode Version 11.6  I also needed to update the library path in my .zshrc (the MacOSX.sdk paths are new):

export CPATH='/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include:/opt/local/include'
export LIBRARY_PATH='/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib:/opt/local/lib'

in the  .cshrc file, I added 

setenv CPATH /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include:/opt/local/include

setenv LIBRARY_PATH /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib:/opt/local/lib

but there are more things to change, before sac will compile and run ., . .. 

Upgrade to MacOS 10.15.6 (Catalina), Some Bookkeeping Notes


Sportsfans,

After upgrading my Macs to MacOS X 10.15.6 Catalina last weekend, a number of compiling links broke and also some third-party software was "relocated".  Because I had delayed upgrading the MacOS from Mojave for over 9 months, the third-party software had adjusted to the new situation.  I downloaded a fresh version of "fink" (rev 0.45.1)   and installed it in the directory /opt/sw, because its old location /sw had been expunged by Apple's update.  This required some changes in my .cshrc file, so that I could point to the correct directories.  I had to upgrade XCode upward three versions, from 10.3 to 10.6, install the Xcode command tools, selfupdate fink, and then run an endless installation procedure to install my favorite X11 text editor nedit.    Took some time, but it all worked.

The older gcc5 compilers in fink were relocated by the MacOS upgrade and had been upgraded to gcc10 in fink.  However, I discovered that my fortran codes were compiling just fine, which meant that they were not using the gfortran compiler in fink.  I found the working gfortran compiler in Anaconda, /Users/jjpark/anaconda/bin/gfortran, so I dropped my .cshrc  pointers to the fink directories for gcc and let them utilize the Anaconda gcc compiler.  The X11 libraries also moved, into /opt, but changing the links fixed that.

So far, so good.  Crossed fingers.

Fearless Leader
 
Link