search

NOAA-EMC / NCEPLIBS-bufr

The NCEPLIBS-bufr library contains routines and utilites for working with the WMO BUFR format.
Other
44 stars 19 forks source link

build test_OUT_3_4_DA.x failing on macOS #68

Closed aerorahul closed 3 years ago

aerorahul commented 3 years ago

Following the latest merge into develop, the test_OUT_3_4_DA.x fails on macOS with GNU 9.3.0

[100%] Linking Fortran executable test_OUT_3_4_DA.x
cd /Users/rmahajan/scratch/bufrWork/python/nceplibs-bufr/build/test && /usr/local/Cellar/cmake/3.18.1/bin/cmake -E cmake_link_script CMakeFiles/test_OUT_3_4_DA.x.dir/link.txt --verbose=YES
/usr/local/bin/gfortran-9  -g -fbacktrace -O3 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk CMakeFiles/test_OUT_3_4_DA.x.dir/test_OUT_3.f.o -o test_OUT_3_4_DA.x  ../src/libbufr_4_DA.a
Undefined symbols for architecture x86_64:
  "_cfe", referenced from:
      _dlloctbf_ in libbufr_4_DA.a(dlloctbf.c.o)
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [test/test_OUT_3_4_DA.x] Error 1
make[1]: *** [test/CMakeFiles/test_OUT_3_4_DA.x.dir/all] Error 2
make: *** [all] Error 2
aerorahul commented 3 years ago

Can someone else please verify this @kgerheiser?

kgerheiser commented 3 years ago

Can confirm. I get the same error.

jbathegit commented 3 years ago

cfe.h is a header file that is included (via "#include cfe.h") within the dlloctbf.c file in the src directory. I don't have a macOS to test on, so not sure what to say here other than this looks like some sort of include issue(?) FWIW, cfe.h is included within the c_hdr list inside of src/list_of_files.cmake

jbathegit commented 3 years ago

Maybe there's some additional compiler flag or option/setting that's needed under macOS, even though it's still the Gnu compiler? Just asking b/c it works fine using Gnu 4.8.5, as well as under the more recent Gnu version in the CI environment.

kgerheiser commented 3 years ago

It is a little strange. I don't see how cfe could not be present. It's included in dlloctbf at compile time.

aerorahul commented 3 years ago

@kgerheiser I see it included when the library is compiled.

aerorahul commented 3 years ago

Is there a timeline for this? Most of our DA developers are using a macOS and this failure in the library test is causing issues at our end. May be put a warning that this library is not supported on macOS or disable the tests on APPLE

kgerheiser commented 3 years ago

My thought of what's happening is this:

cfe is extern, unless you're in inittbf

dlloctbf is being called by EXITBUFR (cfe is extern)

There is no call to inittbf (where cfe not extern)

We are using static libraries so only necessary symbols are resolved (no call to inittbf -> no non-extern cfe -> undefined symbol)

So there's this extern variable with no matching variable definition because there's no call to inittbf.

Why this shows up on Mac only must have something to do with its linker.

Update:

Building with shared libraries resolves the problem

Calling inittbf from inside the routine resolves the problem

The real solution to this issue might be changing the way cfe is defined. I'll think about it a little bit more.