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.
No comments:
Post a Comment