runtime error of real.exe

[papi_p55102]

Dear all

Because of your valuable advices my problem in WPS/metgrid.exe was solved.
(http://forum.mmm.ucar.edu/phpBB3/viewtopic.php?f=31&t=334)
However, real.exe shows error messages as follows;
"real.exe: symbol lookup error: real.exe: undefined symbol: netcdf_".

Compiling WRF seems to be completed and there are real.exe and wrf.exe which size is not zero.
I could not find the answer in FAQ. I will appreciate it if you could give me any advices.

Thank you very much.

I would like to attach some files.

 

[kwthomas]

Hi...

You are using the Portland compiler. Your "configure.wrf" isn't configured perfectly for that.

Try running "ldd" on your "real.exe" file. You'll probably see no library files for "netcdf"
libraries, but files listed for others libraries.

You have multiple optons to fix:

(1) In your NETCDF library directory, there should be files with ".so" and ".a" in them. It is
the ".so" files that causing the problem. Move them to a different place and rebuild. If
there are files that end in .la (I think that is the name), move them too before rebuilding.

Files with .so in them are shared library files that must be available at runtime. File with .a
in them are static archive files. Their code is build into the binary at link time.

(2) Modify the environmental variable LD_LIBRARY_PATH to include the path to your
NETCDF library directory. No recompile is necessary.

(3) Modify "configure.wrf" to use your library files. Look for the "LIB_EXTERNAL" line. Add
a "-Rsomething" where "something" is exactly the same as listed for "-L". No space
between "-R" and "something"! Rebuild.

In all rebuild cases, no "clean -a" is necessary. Just build.

 

[Anonymous]

Hello,

I have encountered this exact error when running real.exe:
./real.exe: symbol lookup error: /share/apps/netcdf/4.2.1.1/intel/13.0.2.146/lib/libnetcdff.so.5: undefined symbol: ncopts

But here is the situation. I am running this on a supercomputer with loadable modules (including NetCDF) and have the same setup in my own account and have done successful runs. I am now trying to get everything set up in a colleague's account but have run into this error. Everything up to this point went smoothly (compiling WRF, generating wrf.exe, real.exe, compiling WPS, generating geogrid, ungrib, and metgrid).

This is WRF 3.9.1.1, compiler option 15 and WPS 3.9.1 compiler option 17. It does look like the NetCDF libraries are recognized, and are version 4.1.3, the identical libraries as the ones I use in my own setup.

I am at a loss to explain the different behavior. The grib files are different than mine, and so the met*.nc files are different, but briefly viewing them in ncview makes it seem like they're fine. Both are GFS analyses on a 0.5° grid, but from different years.

Any clues of what to try would be appreciated, but the ones suggested earlier in this thread were not necessary in my own setup.

Thank you,
Brian

P.S. When I issue "ldd real.exe" here is the output:
linux-vdso.so.1 => (0x00007fff613c8000)
libnetcdff.so.5 => /usr/lib64/libnetcdff.so.5 (0x00007f3023cde000)
libnetcdf.so.7 => /share/opt/MATLAB/R2017a/bin/glnxa64/libnetcdf.so.7 (0x00007f3020990000)
libmpigf.so.4 => /share/opt/intel/impi/4.1.1.036/intel64/lib/libmpigf.so.4 (0x00007f3020760000)
libmpi.so.4 => /share/opt/intel/impi/4.1.1.036/intel64/lib/libmpi.so.4 (0x00007f30200ff000)
libdl.so.2 => /share/sys65/root/lib64/libdl.so.2 (0x00000038d1c00000)
librt.so.1 => /share/sys65/root/lib64/librt.so.1 (0x00000038d2000000)
libpthread.so.0 => /share/sys65/root/lib64/libpthread.so.0 (0x00000038d1800000)
libm.so.6 => /share/sys65/root/lib64/libm.so.6 (0x00000038d2400000)
libc.so.6 => /share/sys65/root/lib64/libc.so.6 (0x00000038d1400000)
libgcc_s.so.1 => /share/sys65/root/lib64/libgcc_s.so.1 (0x00000038d6800000)
libnetcdf.so.6 => /usr/lib64/libnetcdf.so.6 (0x00000038d7400000)
libhdf5_hl.so.6 => /usr/lib64/libhdf5_hl.so.6 (0x00000038d7000000)
libhdf5.so.6 => /usr/lib64/libhdf5.so.6 (0x00007f301fb14000)
libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x0000003786e00000)
libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007f301f822000)
libz.so.1 => /share/sys65/root/lib64/libz.so.1 (0x00000038d1000000)
libssl.so.1.0.0 => /share/opt/MATLAB/R2017a/bin/glnxa64/libssl.so.1.0.0 (0x00007f301f5b0000)
libcrypto.so.1.0.0 => /share/opt/MATLAB/R2017a/bin/glnxa64/libcrypto.so.1.0.0 (0x00007f301f169000)
libhdf5_hl.so.8 => /share/opt/MATLAB/R2017a/bin/glnxa64/libhdf5_hl.so.8 (0x00007f301ef38000)
libhdf5.so.8 => /share/opt/MATLAB/R2017a/bin/glnxa64/libhdf5.so.8 (0x00007f301eaa7000)
/lib64/ld-linux-x86-64.so.2 (0x0000003296400000)
libidn.so.11 => /share/sys65/root/lib64/libidn.so.11 (0x00000038de000000)
libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x0000003786600000)
libgssapi_krb5.so.2 => /share/sys65/root/lib64/libgssapi_krb5.so.2 (0x0000003b36600000)
libkrb5.so.3 => /share/sys65/root/lib64/libkrb5.so.3 (0x0000003b36e00000)
libk5crypto.so.3 => /share/sys65/root/lib64/libk5crypto.so.3 (0x0000003289e00000)
libcom_err.so.2 => /share/sys65/root/lib64/libcom_err.so.2 (0x0000003b36a00000)
libssl3.so => /usr/lib64/libssl3.so (0x0000003784e00000)
libsmime3.so => /usr/lib64/libsmime3.so (0x0000003785600000)
libnss3.so => /usr/lib64/libnss3.so (0x0000003783e00000)
libnssutil3.so => /usr/lib64/libnssutil3.so (0x0000003783a00000)
libplds4.so => /usr/lib64/libplds4.so (0x0000003783600000)
libplc4.so => /usr/lib64/libplc4.so (0x0000003784600000)
libnspr4.so => /usr/lib64/libnspr4.so (0x0000003784200000)
libssh2.so.1 => /usr/lib64/libssh2.so.1 (0x0000003b6dc00000)
liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x0000003786200000)
libresolv.so.2 => /share/sys65/root/lib64/libresolv.so.2 (0x00000038d3000000)
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003785e00000)
libkrb5support.so.0 => /share/sys65/root/lib64/libkrb5support.so.0 (0x0000003289200000)
libkeyutils.so.1 => /share/sys65/root/lib64/libkeyutils.so.1 (0x0000003289a00000)
libssl.so.10 => /usr/lib64/libssl.so.10 (0x0000003b6d400000)
libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x0000003b6d000000)
libcrypt.so.1 => /share/sys65/root/lib64/libcrypt.so.1 (0x00000038d5400000)
libselinux.so.1 => /share/sys65/root/lib64/libselinux.so.1 (0x0000003286200000)
libfreebl3.so => /usr/lib64/libfreebl3.so (0x0000003782e00000)

 

[Anonymous]

I believe I found the culprit. Although this issue might be very sensitive to the exact setup on a given machine, I'll post it here just in case anyone else runs into it. The colleague I am helping had a Matlab module "loaded", and I did not. So I tried unloading it, running real.exe again, and it worked. So there was a conflict that Matlab introduced with the NetCDF libraries.

Anyway, glad it was something so simple, but also had nothing to do with WRF!

Brian

 

[papi_p55102]

Dear kwthomas

I have tried many things for this ten days.
I found that your (2) option is effective and real.exe run.
However using all (1),(2) and (3) was not effective.

Moreover, real.exe run by using (2), but there is some other problem.
Later I may ask in the forum.

Anyway, kwthomas, I appreciate your valuable comments.