CMake broken

[rmclaren]

Current behavior (describe the bug)

CMake is totally hosed when I try to compile whats in the develop branch. Running MacOS, gcc-13, and cmake version 3.27.7... I have no idea why this is, but basically CMake stops finding packages when I try to use this branch (ex follows [if I fix this issue by manually specifying the exact path the library is at I just end up with more issues like this]). Works ok when I switch to a different branch (ex: feature/query_new_result)... I have lost so much time over this issue, thinking I'd messed up my local environment somehow...

-- [iodaconv] (0.0.1) [9ceef77] -- Feature TESTS enabled -- Feature PKGCONFIG enabled -- Found Python3: /usr/local/bin/python3.11 (found version "3.11.6") found components: Interpreter Development Development.Module Development.Embed -- Performing Test HAS_FLTO -- Performing Test HAS_FLTO - Failed -- Looking for Fortran sgemm -- Looking for Fortran sgemm - not found -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success -- Found Threads: TRUE
-- Looking for Fortran sgemm -- Looking for Fortran sgemm - not found -- Looking for Fortran dgemm -- Looking for Fortran dgemm - not found -- Looking for Fortran dgemm -- Looking for Fortran dgemm - not found -- Looking for Fortran sgemm -- Looking for Fortran sgemm - not found CMake Error at /usr/local/Cellar/cmake/3.27.7/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find BLAS (missing: BLAS_LIBRARIES) Call Stack (most recent call first): /usr/local/Cellar/cmake/3.27.7/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE) /usr/local/Cellar/cmake/3.27.7/share/cmake/Modules/FindBLAS.cmake:1383 (find_package_handle_standard_args) /usr/local/Cellar/cmake/3.27.7/share/cmake/Modules/FindLAPACK.cmake:247 (find_package) /usr/local/Cellar/cmake/3.27.7/share/cmake/Modules/FindLAPACK.cmake:283 (_lapack_find_dependency) /usr/local/Cellar/cmake/3.27.7/share/cmake/Modules/CMakeFindDependencyMacro.cmake:76 (find_package) /Users/rmclaren/Work/installs/lib/cmake/oops/oops-import.cmake:18 (find_dependency) /Users/rmclaren/Work/installs/lib/cmake/oops/oops-config.cmake:83 (include) /Users/rmclaren/Work/installs/share/ecbuild/cmake/ecbuild_find_package.cmake:239 (find_package) CMakeLists.txt:63 (ecbuild_find_package)

Expected behavior

Should find packages and build.

[rmclaren]

Problems started with the following revision 7c9c0fc4f4c8e1bf24c52f132e84653a1321e821. I worked backwards until I hit the problem...

[rmclaren]

This is the offending line include( compiler_flags_GNU_Fortran )... When I replace it include( compiler_flags_Clang_GNU_Fortran ) it works.... (Installed libs via homebrew)...

[rmclaren]

I think Homebrew is compiling the fortran libs with clang.... Ugg... Think Macports does it differently (not sure), maybe uses the "active" compiler configured via macports... Dunno...

[rmclaren]

I think the root reason is that when you compile with compiler_flags_GNU_Fortran then you set the mcmodel-medium flag. But since non of the libraries are compile this way they are not compatible (and ignored). I guess we can always set compiler_flags_Clang_GNU_Fortran if on Apple (since we are developing). No idea...

[rmclaren]

Uggg...

[ 50%] Linking Fortran executable ../../bin/bufr2nc_fortran.x
final section layout:
    __TEXT/__text addr=0x1000012D4, size=0x00103572, fileOffset=0x000012D4, type=1
    __TEXT/__stubs addr=0x100104846, size=0x0000029A, fileOffset=0x00104846, type=29
    __TEXT/__const addr=0x100104AE0, size=0x0000DC10, fileOffset=0x00104AE0, type=0
    __TEXT/__cstring addr=0x1001126F0, size=0x00023A77, fileOffset=0x001126F0, type=13
    __TEXT/__eh_frame addr=0x100136168, size=0x00005E88, fileOffset=0x00136168, type=19
    __DATA_CONST/__got addr=0x10013C000, size=0x00000AD0, fileOffset=0x0013C000, type=31
    __DATA_CONST/__const addr=0x10013CAE0, size=0x00000810, fileOffset=0x0013CAE0, type=0
    __DATA/__data addr=0x100140000, size=0x00002F32, fileOffset=0x00140000, type=0
    __DATA/__common addr=0x100142F40, size=0x0004F758, fileOffset=0x00000000, type=26
    __DATA/__bss addr=0x1001926A0, size=0x000D5C10, fileOffset=0x00000000, type=26
    __DATA/__huge addr=0x1002682C0, size=0xB45E5100, fileOffset=0x00000000, type=26
ld: 32-bit RIP relative reference out of range (2664294666 max is +/-2GB): from ___ahi_hsd_mod_MOD_read_hsd (0x100012E67) to ___ahi_hsd_mod_MOD_satzen (0x19ED16840) in '___ahi_hsd_mod_MOD_read_hsd' from CMakeFiles/bufr2nc_fortran.x.dir/hsd.f90.o for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [bin/bufr2nc_fortran.x] Error 1
make[1]: *** [src/ncar-bufr2nc-fortran/CMakeFiles/bufr2nc_fortran.x.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

[PatNichols]

@rmclaren Some of this might be fixed with recently merged PR https://github.com/JCSDA-internal/ioda-converters/pull/1399 ... The cmake is a mess right now but hopefully we no longer need the mcmodel flag. The apple clang compilers for the arm chips, apple M1 and M2, had some "features" that produced some crashes. The bug you see with the RIP is due to not using mcmodel flags for gcc on linux where it was needed. I need to check what the new flags should be after the merger above and do a new quick PR.

[rmclaren]

@PatNichols Thanks!