OCSSW built problem: third-party sources (sdptk) compilation hangs

[erehm]

I am trying to rebuild l2gen with OCSSW_DEBUG=ON.
So, first I must build the third party sources at occsw/opt/src (doing this with OCSSW_DEBUG=OFF).
I am following the build instructions at https://oceancolor.gsfc.nasa.gov/docs/ocssw/

1. I downloaded the latest code
$ cd $OCSSWROOT/opt
$ wget https://oceandata.sci.gsfc.nasa.gov/ocssw/opt-src.tar
$ tar -xvf opt-src.tar

2. When I do ./BuildIt from ocssw/opt/src/BuildIt, the compiler hangs on ocssw/opt/src/sdptk/TOOLKIT/obj/macintel64/CUC/prtlabel.c
/usr/bin/gcc -fPIC -c  -DMACINTEL -O -DSUN_UNIX -I.  -I/Applications/seadas-7.5.1/ocssw/opt/src/sdptk/TOOLKIT/include -I/Applications/seadas-7.5.1/ocssw/opt/src/sdptk/TOOLKIT/include/CUC  prtlabel.c -o /Applications/seadas-7.5.1/ocssw/opt/src/sdptk/TOOLKIT/obj/macintel64/CUC/prtlabel.o
prtlabel.c:325:22: warning: enumeration value 'TV_NULL' not handled in switch [-Wswitch]
(Hangs here ...have to ctrl-c to interrupt)

Details:
- MacOS 10.14.5 (Mojave)
- gcc / g++
gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1xx.xxx.xx.xx)
Target: x86_64-apple-darwin18.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[gnwiii]

With luck, someone with Mohave will be able to suggest a working configuration.  My MacOS experience is from El Capitan, but I can provide some background that may help you find a working solution.  There are many more people with experience building l2gen on linux than on MacOS Mohave, so you might also consider using a virtual machine running linux.

Apple stopped providing a real GNU Compiler Collection (GCC) tools years ago, see gcc with MacOS Lion, and has never provided gfortran.   GFortran binaries for MacOS offers many ways to get gfortran.   To build l2gen, however, matching versions of gcc and g++ are needed.  The GFortran binaries page lists 4 projects that can install the GCC (gcc, g++, and gfortran).  

Current versions of GCC may have bugs and often need additional flags to build legacy code, so you should look for an older GCC version.  The build instructions say "4.5 or higher", and mention "gcc-5".  You can also check the version of the gfortran library.  On linux it is "libgfortran.so.3", which is used by gcc-5 and gcc-6.  Macports tries to support legacy compilers, but there can be problems installing legacy compilers on much newer MacOS versions.

[OB.DAAC - SeanBailey]

Eric,
George is correct, you'll need to install a GCC suite (c, c++ and fortran) as the compiler on the Mac doesn't play well with the code....and you need FORTRAN...
The build machine we used for the Mac distribution is a High Sierra system with gcc-5 from Macports.  I have a Mojave system with gcc-8 and have successfully built the code.

Sean

[erehm]

Thanks everyone for the quick response.

Yes, I have gfortran installed (I would not have gotten very far without that ;-)) . But I didn't realize that Apple's gcc/g++ didn't play will with others.  I have Macports installed, so I'll follow Sean's suggestions.

(It's still quite baffling to me - I've never seen a compiler reliably hang at the same point when compiling a source module before.)

[OB.DAAC - SeanBailey]

Yes, that is an odd thing, but so is the sdptk code :eek:

Sean

[gnwiii]

I used to routinely test new compilers on a several large codes, including the OCSSW tools.   This is less important now that compiler developers can afford the processing power to run extensive tests.  Testing has become more difficult due to an ever growing list of default optimizations, some of which need to be disabled ("-fno-optimize-sibling-calls") for legacy code (e.g., lapack) and efforts to eliminate potential out-of-bounds memory access at compile time.   Efforts to improve error reporting started with GCC 9.

In the past couple years I've encountered more hang events than "internal compiler error" (ICE) events.   The simple solution is to use a toolchain that works for others.  Extracting an minimal example in order to file a bug report from the sdptk code would not be easy, and the few cases I have investigated led to either "known bug, fixed in next release" or "code relies on undefined behaviour, will not fix".