On Tuesday, July 8, 2014, Simon Urbanek <simon.urbanek@r-project.org> wrote:

> For posterity: this message got apparently suck in some queue - the issue
> has been resolved off-list in the mean time where simply HDF5 binary was
> not installed on the build machine.
>
> Cheers,
> Simon
>
>
Hi Simon,

Just wanted to check on this. I looked just now at the ncdf4 build log on
CRAN and it still seems to be giving the same error...?

Dave,



> On Jun 20, 2014, at 6:14 PM, David W. Pierce <dpierce@ucsd.edu
> <javascript:;>> wrote:
>
> > Hello,
> >
> > I'm the package maintainer for ncdf4, which provides an R interface
> > for netcdf files. I have successfully built and installed the package
> > on a OS X Mavericks machine I have access to, but the nightly build on
> > that platform for R failed with an error I'm trying to understand.
> >
> > I'm sure it's documented somewhere who to contact about odd results on
> > the specific Mavericks machine used for the CRAN compiles, but I have
> > not been able to find that despite some searching. Does anyone know if
> > there's a contact who can be approached about the software environment
> > of that particular machine?
> >
> > More technical details of the compiling problem follow.
> >
> > The netcdf library has an accessory script that shows how it was
> > configured on the machine in question (the Mavericks machine in this
> > case). This shows:
> >
> > ------
> >
> > This netCDF 4.1.3 has been built with the following features:
> >
> >  --cc        -> gcc -arch i386 -std=gnu99
> >  --cflags    ->  -I/usr/local/include
> >  --libs      -> -L/usr/local/lib  -lnetcdf -lhdf5_hl -lhdf5 -lm -lz
> -lcurl
> >
> > -----
> >
> > which is stating that the library compiled correctly using
> > -L/usr/local/lib -lhdf4_hl (among other libs). Yet the R build failed
> > with:
> >
> > clang -dynamiclib -Wl,-headerpad_max_install_names -undefined
> > dynamic_lookup -single_module -multiply_defined suppress
> > -L/usr/local/lib -o ncdf4.so ncdf.o ncdf2.o ncdf3.o src_ncdf4.o
> > -Wl,-rpath,/usr/local/lib -L/usr/local/lib -lnetcdf -lhdf5_hl -lhdf5
> > -lm -lz -lcurl -F/Library/Frameworks/R.framework/.. -framework R
> > -Wl,-framework -Wl,CoreFoundation
> > ld: library not found for -lhdf5_hl
> > clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> >
> > which claims that -lhdf5_hl was not found. The odd part is, if that
> > library was found when the netcdf library was compiled, why wasn't it
> > found when the R ncdf4 package was compiled with the same -L library
> > path flag? Am I missing something here?
> >
> > Also, I know essentially nothing about Macs (hopefully some people
> > here can help me on this), but I see that the netcdf library was
> > compiled with "-arch i386", while the R package was compiled with
> > "clang -Wall -mtune=core2 -g -O2", which does not specify -arch i386.
> > Is it possible that the linker is reporting "hdf5_hl" not found
> > because the existing library is a 32-bit library but it's looking for
> > a 64-bit library? On Windows, for example,this would give an error
> > along the lines of "library is 32 bit not 64 bit" but I don't know how
> > OS X would handle this.
> >
> > Thanks for any info,
> >
> > --Dave
> >
> > --
> > Dr. David W. Pierce
> > Division of Climate, Atmospheric Science, and Physical Oceanography
> > Scripps Institution of Oceanography, La Jolla, California, USA
> > (858) 534-8276 (voice)  /  (858) 534-8561 (fax)    dpierce@ucsd.edu
> <javascript:;>
> >
> > _______________________________________________
> > R-SIG-Mac mailing list
> > R-SIG-Mac@r-project.org <javascript:;>
> > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> >
>
>

-- 
David W. Pierce
Division of Climate, Atmospheric Science, and Physical Oceanography
Scripps Institution of Oceanography, La Jolla, California, USA
(858) 534-8276 (voice)  /  (858) 534-8561 (fax)    dpierce@ucsd.edu

	[[alternative HTML version deleted]]

