[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #QGH-450146]: building netcdf4.2 on suse linux enterprise server 11 with ifort

Hi Felipe,

> I am having problem building netcdf4.2 on suse server 11 with ifort. I have
> installed zlib1.2.6 and hdf5.1.8.8. Apparently everything is installed
> correctly. However, when I tried to make check netcdf I am getting these
> errors:
> mv -f $depbase.Tpo $depbase.Po
> /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -L/usr/lib -o
> tst_h_dimscales4 tst_h_dimscales4.o -lhdf5_hl -lhdf5 -lm -lz
> libtool: link: gcc -g -O2 -o tst_h_dimscales4 tst_h_dimscales4.o
> -L/usr/lib /usr/lib/libhdf5_hl.so /usr/lib/libhdf5.so -lrt -lm -lz
> make[2]: Leaving directory `/data1/netcdf-4.2/h5_test'
> make check-TESTS
> make[2]: Entering directory `/data1/netcdf-4.2/h5_test'
> ./tst_h_files: error while loading shared libraries: libhdf5_hl.so.7:
> cannot open shared object file: No such file or directory
> FAIL: tst_h_files
> ./tst_h_files2: error while loading shared libraries: libhdf5_hl.so.7:
> cannot open shared object file: No such file or directory
> FAIL: tst_h_files2
> ================================================
> 26 of 26 tests failed
> Please report to address@hidden
> ================================================
> make[2]: *** [check-TESTS] Error 1
> make[2]: Leaving directory `/data1/netcdf-4.2/h5_test'
> make[1]: *** [check-am] Error 2
> make[1]: Leaving directory `/data1/netcdf-4.2/h5_test'
> make: *** [check-recursive] Error 1
> When checking the net I found descriptions of the same error and it was
> said to include LD_LIBRARY_PATH what I did.

That won't work in this case for two reasons:

  1.  You installed libraries in /usr/lib, and that is already a
      default search directory for shared libraries, so it never needs
      to be added to LD_LIBRARY_PATH.
  2.  To use the Intel compilers, you probably had to source some
      shell command script that would set LD_LIBRARY_PATH to a list of
      directories containing run-time libraries for ifort and perhaps
      other Intel compilers.  By setting LD_LIBRARY_PATH to /usr/lib,
      *after* running the Intel command script, those library paths
      are no longer set, which explains why the netCDF configure
      script failed with 

> Then I ran the configure command with the following command:
> CPPFLAGS=-I/usr/include LDFLAGS=-L/usr/lib ./configure --disable-doxygen
> --prefix=/usr
> But when I do that I get the errror:
> configure: netCDF 4.2
> checking whether the C compiler works... no
> configure: error: in `/data1/netcdf-4.2':
> configure: error: C compiler cannot create executables

because, as the config.log shows, 

> configure:4094: checking whether the C compiler works
> configure:4116: gcc -I/usr/include -L/usr/lib conftest.c >&5
> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/as:
> error while loading shared libraries: libimf.so: cannot open shared object
> file: No such file or directory

and "libimf.so" is required by the Intel compilers, installed in some
directory that would have been in LD_LIBRARY_PATH.

> configure:4120: $? = 1
> configure:4158: result: no
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "netCDF"
> | #define PACKAGE_TARNAME "netcdf"
> | #define PACKAGE_VERSION "4.2"
> | #define PACKAGE_STRING "netCDF 4.2"
> | #define PACKAGE_BUGREPORT "address@hidden"
> | #define PACKAGE_URL ""
> | #define PACKAGE "netcdf"
> | #define VERSION "4.2"
> | #define NCIO_MINBLOCKSIZE 256
> | #define USE_FSYNC 1
> | #define DEFAULT_CHUNK_SIZE 4194304
> | #define MAX_DEFAULT_CACHE_SIZE 67108864
> #define CHUNK_CACHE_SIZE 4194304
> | #define CHUNK_CACHE_NELEMS 1009
> | /* end confdefs.h. */
> |

> declare -x LD_LIBRARY_PATH="/usr/lib"

That's the one that's the problem, preventing the Intel C compiler
or Fortran compiler from working.  If you had a directory other than
the default "/usr/lib" that you wanted to add to LD_LIBRARY_PATH, such
as "/usr/local/lib", a better way to set it so that the existing
LD_LIBRARY_PATH entries would still be preserved, would be something


As for the original problem, 

> ./tst_h_files: error while loading shared libraries: libhdf5_hl.so.7:
> cannot open shared object file: No such file or directory
> FAIL: tst_h_files

I'm not sure why it's not found, if you installed it in /usr/lib.
Some possible reasons are:

  - The installed library is 32-bit and you need a 64-bit library for
    the compiler you are using
  - There is another old instance of libhdf5_hl.so installed somewhere
    that has to be removed to get the linker to find the right one
  - The installation of HDF5 was incomplete or interrupted, so that
    the symbolic links needed in the /usr/lib directory to locate the
    right version of the library were not created and installed.  For
    example, my installation has the following:

  lrwxrwxrwx 1       19 Dec  1 13:59 libhdf5_hl.so -> libhdf5_hl.so.7.0.2*
  lrwxrwxrwx 1       19 Dec  1 13:59 libhdf5_hl.so.7 -> libhdf5_hl.so.7.0.2*
  -rwxr-xr-x 1   335559 Dec  1 13:59 libhdf5_hl.so.7.0.2*

  - The permissions or owner on the library are wrong, so that you
    can't access it ...

There are probably other possibilities as well, but I can't tell from
the information provided.  You might try address@hidden or even
Intel support to determine what the root of the problem is, if it's
not one of the above guesses ...


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

Ticket Details
Ticket ID: QGH-450146
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.