> So I ignore this -lsz and tried to again. > The config seemed to work (again attached). Yes, sorry about that, the "-lsz" should not have been included in LIBS if the HDF5 library was not built with szlib, and that's not needed for netCDF-4. > Compilation failed though with this error msg: > libtool: link: gcc -shared -fPIC -DPIC .libs/libnetcdf_la-stub.o > -Wl,--whole-archive ../libdispatch/.libs/libnetcdf2.a > ../libdispatch/.libs/libdispatch.a ../libsrc/.libs/libnetcdf3.a > ../libdap2/.libs/libdap2.a ../oc/.libs/liboc.a > ../libsrc4/.libs/libnetcdf4.a -Wl,--no-whole-archive -Wl,-rpath > -Wl,/usr/local/hdf5/lib -Wl,-rpath -Wl,/usr/local/hdf5/lib > -L/usr/local/hdf5/lib -L/usr/local/hdf4/lib -L/usr/lib/x86_64-linux-gnu > /usr/local/hdf4/lib/libmfhdf.a /usr/local/hdf4/lib/libdf.a -ljpeg > /usr/local/hdf5/lib/libhdf5_hl.so /usr/local/hdf5/lib/libhdf5.so -lrt -lm > -lz /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so -O2 -Wl,-soname > -Wl,libnetcdf.so.7 -o .libs/libnetcdf.so.7.2.0 > /usr/bin/ld: /usr/local/hdf4/lib/libmfhdf.a(mfsd.o): relocation R_X86_64_32 > against `.rodata.str1.1' can not be used when making a shared object; > recompile with -fPIC > /usr/local/hdf4/lib/libmfhdf.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > make[1]: *** [libnetcdf.la] Error 1 > make[1]: Leaving directory > `/home/saulo/extra_software/netcdf-4.2.1.1/liblib' > make: *** [check-recursive] Error 1 > > Any idea how can I fix this? You could try including "-fPIC" in CFLAGS before running configure when compiling HDF4. Alternatively, building HDF4 as a shared library may work. Sorry we don't have a definitive answer for this. Currently our test build with HDF4 is not working on our snapshot release, although I believe it was working with 4.2.1.1. Of course another solution would be to build without --enable-hdf4, but I'm assuming you have a need for the limited HDF4 reading capabilities in the netCDF-4 C libraries. --Russ > On Mon, Sep 24, 2012 at 2:06 PM, Saulo Soares <address@hidden> wrote: > > > Hi Russ, > > > > Thanks for looking into this. > > I had tried the HDF4 with --disable-netcdf before and it didn't work but I > > rebuilt it again with --disable-netcdf anyway. > > I tried your LIBS choice but now the configure fails: > > > > checking whether the C compiler works... no > > configure: error: in `/home/saulo/extra_software/netcdf-4.2.1.1': > > configure: error: C compiler cannot create executables > > See `config.log' for more details > > > > Atthached is the log, it seems I don't have this -lsz lib. > > > > Thanks > > Saulo > > > > > > address@hidden> wrote: > > > >> Saulo, > >> > >> I also see a presentation on using HDF4 with netCDF from several years ago > >> that had slide 19 with the following bullet text: > >> > >> - This feature cannot be used at the same time as > >> HDF4's netCDF v2 API, because HDF4 steals > >> the netCDF v2 API function names. So you > >> must use --disable-netcdf when building HDF4. > >> (It might also work to âdisable-v2 for the > >> netCDF build.) > >> > >> I don't know if the problem you are seeing is related to this, but it may > >> be a good idea to build the HDF4 library using the --disable-netcdf option > >> to the configure script. > >> > >> --Russ > >> > >> > Hi Saulo, > >> > > >> > Sorry to have taken so long to respond to your question ... > >> > > I've attached my config log in case it may help. > >> > > >> > Yes, it looks like the hdf4 library, which you have installed in > >> /usr/local/hdf4/lib/, > >> > is not being searched. Could you try running the configure script > >> again with the > >> > CPPFLAGS and LDFLAGS you used, but also adding the definition > >> > > >> > LIBS='-lmfhdf -ldf -lhdf5_hl -lhdf5 -lsz -lm -lz -lcurl' > >> > > >> > The "-lmfhdf -ldf" tell the linker to explicitly search the HDF4 > >> libraries in the > >> > directories you specified in LDFLAGS. I don't know whether the > >> configure script is > >> > supposed to do this automatically, but if so, it appears to have a bug . > >> > > >> > --Russ > >> > > >> > > address@hidden> wrote: > >> > > > >> > > > > >> > > > Saulo Soares, > >> > > > > >> > > > Your Ticket has been received, and a Unidata staff member will > >> review it > >> > > > and reply accordingly. Listed below are details of this new Ticket . > >> Please > >> > > > make sure the Ticket ID remains in the Subject: line on all > >> correspondence > >> > > > related to this Ticket. > >> > > > > >> > > > Ticket ID: UYL-334118 > >> > > > Subject: FAIL: run_tests.sh > >> > > > Department: Support netCDF > >> > > > Priority: Normal > >> > > > Status: Open > >> > > > > >> > > > > >> > > > > >> > > > The NetCDF libraries are developed at the Unidata Program Center, > >> > > > in Boulder, Colorado, funded primarily by the National Science > >> Foundation. > >> > > > > >> > > > All support requests are handled by the development team. No > >> dedicated > >> > > > support staff are funded at this time. For this reason we cannot > >> guarantee > >> > > > response times, nor that we can resolve every support issue, > >> although we > >> > > > do our best to respond within 72 hours. > >> > > > > >> > > > It is in the nature of support requests that the same question is > >> asked > >> > > > many > >> > > > times. We urge you to search the support archives for material > >> relating to > >> > > > your support request: > >> > > > > >> > > > http://www.unidata.ucar.edu/search.jsp?support&netcdf > >> > > > > >> > > > If you are having trouble building netCDF, please take a look at the > >> > > > "Building NetCDF" page: > >> > > > > >> > > > http://www.unidata.ucar.edu/software/netcdf/docs/building.html > >> > > > > >> > > > or the (unfortunately somewhat out-of-date) NetCDF Build > >> Troubleshooter > >> > > > page: > >> > > > > >> > > > http://www.unidata.ucar.edu/software/netcdf/docs/troubleshoot.html > >> > > > > >> > > > Windows users should see the FAQ list: > >> > > > > >> > > > > >> http://www.unidata.ucar.edu/software/netcdf/docs/faq.html#windows_netcdf4_2 > >> > > > > >> > > > Complete documentation (including a tutorial, and sample programs > >> in C, > >> > > > Fortran, > >> > > > Java, and other programming languages) can be found on the netCDF > >> > > > Documentation page: > >> > > > > >> > > > http://www.unidata.ucar.edu/software/netcdf/docs/ > >> > > > http://www.unidata.ucar.edu/software/netcdf/examples/programs/ > >> > > > > >> > > > If you resolve your issue through one of these methods, please send > >> a > >> > > > reply to > >> > > > this email, letting us know that you no longer need support. This > >> will help > >> > > > us spend more time on netCDF development. > >> > > > > >> > > > Best regards, > >> > > > > >> > > > Unidata User Support > >> > > > > >> > > > > >> > > > >> > > > >> > Russ Rew UCAR Unidata Program > >> > address@hidden http://www.unidata.ucar.edu > >> > > >> > > >> Russ Rew UCAR Unidata Program > >> address@hidden http://www.unidata.ucar.edu > >> > >> > >> > >> Ticket Details > >> =================== > >> Ticket ID: UYL-334118 > >> Department: Support netCDF > >> Priority: Normal > >> Status: Closed > >> > >> > > > > Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: UYL-334118 Department: Support netCDF Priority: Normal Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.