[netCDF #XEG-354991]: OS X binary

Hi Tim,

> I haven't found a way that I can find to build or obtain a functioning
> 64-bit, static netCDF 4.1.2 library (or 4.anything for that matter)
> for OS X. The link to the binary on your pdf site is broken (I checked
> and it's not there) and configure stops with the message:
> 
> "configure:26866: error: Can't find or link to the hdf5 library. Configure 
> with --with-hdf5, or use       --disable-netcdf-4, or see config.log for 
> errors."
> 
> This appears to be because the linker can't find "H5Fflush". I've
> installed the current official release (1.8.6) of HDF5 64-bit static
> library. My HDF5 path points to the top of the HDF5 tree, it contains
> references to "H5Fflush" in H5Fpublic.h and libhdf5.a and I've run
> h5redeploy, so I'm at a loss.
> 
> I've wasted days on this. Please, please, please, please release a
> functioning netcdf 4.1.2 64-bit static library for OS X.

What you've described can be a symptom for several possible problems:

  - a mismatch in 64-bit and 32-bit objects, for example a netCDF library
    built with as a 64-bit library looking for a 64-bit HDF5 library but
    instead finding a 32-bit library, caused by installing an HDF5 library
    of a different architecture than what's specified or used by default by
    the C compiler.

  - a leftover library installed in a preious installation but for the wrong
    architecture, for example a shared HDF5 library of the wrong architecture in
    /usr/local/lib/ or /usr/lib/, searched first even when specifying a 
different
    location in the --with-hdf5= option.

For example, If you are using cc -m64 or a C compiler that builds 64-bit objects
by default, and it finds 32-bit shared libraries for HDF5 in /usr/local/lib/, 
you
should delete all those first.  They could be found using something like:

  $ file /usr/local/lib/*.dylib | grep hdf5
  /usr/local/lib/libhdf5.6.dylib:     Mach-O dynamically linked shared library 
i386
  /usr/local/lib/libhdf5_hl.6.dylib:  Mach-O dynamically linked shared library 
i386

which would be 32-bit libraries, and should be deleted before proceeding.

This mismatched architectures problem also occurs becasue Fortran compilers g95 
and
gfortran compile for different architectures by default on MacOS-X in my 
experience.

I hope this helps.  We have some examples of successful compiles on MacOS X:

  make clean && CPPFLAGS= CC=cc CFLAGS='-g -m32' CXX=g++ CXXFLAGS='-g -m32' 
FC=g95 FCFLAGS='-g -m32' F77=g95 FFLAGS='-g -O2' LDFLAGS= LIBS= FLIBS= F90LIBS= 
./configure --disable-compiler-recover --enable-netcdf-4 
--with-hdf5=/share/ed/local/mort_32 && make check install

  make clean && CPPFLAGS= CC=cc CFLAGS='-g -m32' CXX=g++ CXXFLAGS='-g -m32' 
FC=g95 FCFLAGS='-g -m32' F77=g95 FFLAGS='-g -O2' LDFLAGS= LIBS= FLIBS= F90LIBS= 
./configure --disable-compiler-recover --enable-netcdf-4 
--with-hdf5=/share/ed/local/mort && make check install

  make clean && CPPFLAGS= CC=cc CFLAGS='-g -m32' CXX=g++ CXXFLAGS='-g -m32' 
FC=g95 FCFLAGS='-g -m32' F77=g95 FFLAGS='-g -O2' LDFLAGS= LIBS= FLIBS= F90LIBS= 
./configure --disable-compiler-recover --with-udunits --enable-netcdf-4 
--with-hdf5=/share/ed/local/mort && make check install

  make clean && CPPFLAGS= CC=cc CFLAGS='-g -m32' CXX=g++ CXXFLAGS='-g -m32' 
FC='gfortran -m32' FCFLAGS='-g' F77='gfortran -m32' FFLAGS='-g -O2' 
CPPFLAGS='-DNDEBUG -DgFortran' LDFLAGS=-m32 LIBS= FLIBS= F90LIBS= ./configure 
--disable-compiler-recover --with-udunits --enable-netcdf-4 
--with-hdf5=/share/ed/local/mort && make check install

--Russ


  
Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: XEG-354991
Department: Support netCDF
Priority: Normal
Status: Closed