On 7/5/18 10:19 AM, Thompson, Matt (GSFC-610.1)[SCIENCE SYSTEMS AND
APPLICATIONS INC] wrote:
Dear netCDF Gurus,
First, I mistakenly opened an issue on Github for this not realizing
(after reading the README.md) that this is the preferred bug question
place. Sorry!
My build of netcdf-C 4.6.1 on macOS 10.13.5 isn't quite working. I'm
building with GCC 8.1.0 (built from source) and Open MPI 3.1.0. I built
HDF5 with --enable-parallel so mpicc is my C compiler in this stage.
From my scan of the build log, libnetcdf.a is made, but when ocprint
tries to link I get:
make[4]: Entering directory
'/Users/mathomp4/Baselibs/ESMA-Baselibs-5.1.2/src/netcdf/ncdump'
/bin/sh ../libtool --tag=CC --mode=link mpicc -o ocprint
ocprint.o ../liblib/libnetcdf.la -ljpeg -lmfhdf -ldf -lhdf5_hl -lhdf5
-lm
-L/Users/mathomp4/installed/MPI/gcc-gfortran-8.1.0/openmpi-3.1.0/Baselibs/5.1.2/Darwin/lib
-lmfhdf -ldf -lsz -ljpeg
-L/Users/mathomp4/installed/MPI/gcc-gfortran-8.1.0/openmpi-3.1.0/Baselibs/5.1.2/Darwin/lib
-lcurl -lz -lm -ldl -lm
libtool: link: mpicc -o ocprint ocprint.o ../liblib/.libs/libnetcdf.a
-L/Users/mathomp4/installed/MPI/gcc-gfortran-8.1.0/openmpi-3.1.0/Baselibs/5.1.2/Darwin/lib
/Users/mathomp4/installed/MPI/gcc-gfortran-8.1.0/openmpi-3.1.0/Baselibs/5.1.2/Darwin/lib/libhdf5_hl.a
/Users/mathomp4/installed/MPI/gcc-gfortran-8.1.0/openmpi-3.1.0/Baselibs/5.1.2/Darwin/lib/libhdf5.a
/Users/mathomp4/installed/MPI/gcc-gfortran-8.1.0/openmpi-3.1.0/Baselibs/5.1.2/Darwin/lib/libmfhdf.a
/Users/mathomp4/installed/MPI/gcc-gfortran-8.1.0/openmpi-3.1.0/Baselibs/5.1.2/Darwin/lib/libdf.a
/Users/mathomp4/installed/MPI/gcc-gfortran-8.1.0/openmpi-3.1.0/Baselibs/5.1.2/Darwin/lib/libsz.a
/Users/mathomp4/installed/MPI/gcc-gfortran-8.1.0/openmpi-3.1.0/Baselibs/5.1.2/Darwin/lib/libjpeg.a
/Users/mathomp4/installed/MPI/gcc-gfortran-8.1.0/openmpi-3.1.0/Baselibs/5.1.2/Darwin/lib/libcurl.a
-lz -ldl -lm
Undefined symbols for architecture x86_64:
"_ncrc_globalstate", referenced from:
_createtempfile in libnetcdf.a(liboc_la-ocinternal.o)
_ocset_curlproperties in libnetcdf.a(liboc_la-ocinternal.o)
_NC_rcload in libnetcdf.a(libdispatch_la-drc.o)
_NC_set_rcfile in libnetcdf.a(libdispatch_la-drc.o)
_rccompile in libnetcdf.a(libdispatch_la-drc.o)
_rclocate in libnetcdf.a(libdispatch_la-drc.o)
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:1046: ocprint] Error 1
make[4]: Leaving directory
'/Users/mathomp4/Baselibs/ESMA-Baselibs-5.1.2/src/netcdf/ncdump'
make[3]: *** [Makefile:1265: install-recursive] Error 1
make[3]: Leaving directory
'/Users/mathomp4/Baselibs/ESMA-Baselibs-5.1.2/src/netcdf/ncdump'
make[2]: *** [Makefile:672: install-recursive] Error 1
make[2]: Leaving directory
'/Users/mathomp4/Baselibs/ESMA-Baselibs-5.1.2/src/netcdf'
make[1]: *** [GNUmakefile:898: netcdf.install] Error 2
make[1]: Leaving directory
'/Users/mathomp4/Baselibs/ESMA-Baselibs-5.1.2/src'
make: *** [GNUmakefile:267: install] Error 2
As a test, I took netcdf-C 4.5.0 (which had worked before on this
machine) and tried building it instead (feeding in the exact same
libraries that went into the build above) and ocprint, etc all built
just fine. So I'm missing something in my configure or LIBS or something
that ocprint, et al, now need to build. Any ideas?
Hmm. Query for the list: Is ocprint supposed to be built? I use
autotools/configure to make my library but I thought I'd troll around
the CMakeLists.txt files to see if ocprint was being built/linked with
extra libraries perhaps. When I did so I see:
# Apparently fails under cmake
#set(ocprint_FILES ocprint.c )
#ADD_EXECUTABLE(ocprint ${ocprint_FILES})
#TARGET_LINK_LIBRARIES(ocprint oc2 ${ALL_TLL_LIBS})
(which is in the oc2/CMakeLists.txt, not the ncdump/CMakeLists.txt).
Huh. Indeed, the autotools build seems to build things that CMake
doesn't (e.g., nc4print which doesn't seem to appear in any
CMakeLists.txt file in the tarball...and isn't installed, just built?).
Is there a way to get autotools build to skip ocprint? I honestly do not
need it (I don't even know what it does) so if I can avoid it...
Matt
--
Matt Thompson, SSAI, Sr Scientific Programmer/Analyst
NASA GSFC, Global Modeling and Assimilation Office
Code 610.1, 8800 Greenbelt Rd, Greenbelt, MD 20771
Phone: 301-614-6712 Fax: 301-614-6246
http://science.gsfc.nasa.gov/sed/bio/matthew.thompson