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

[netCDF #QYP-982325]: NetCDF fortran enddef crashing program

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [netCDF #QYP-982325]: NetCDF fortran enddef crashing program
  • Date: Wed, 29 Jan 2014 22:23:28 -0700
Joel,

> Thank you! I set and exported the LD_LIBRARY_PATH environment variable in
> my .bash_profile file, which eliminated all the issues I was having
> building netcdf-fortran-4.2
> 
> My code will compile and ldd indicates that it's finding and linking
> everything appropriately. However, upon trying to run the program I get an
> error that it can't open or find the libnetcdff.so.5 file, which definitely
> exists and is linked according to the ldd output. I've included a text file
> summarizing this from command line output.
> 
> Any ideas on why this library can not be located and opened, yet it is
> allegedly linked correctly?

Shared libraries can be difficult to use if they're not installed in a standard
location where the dynamic linker/loader, ld-linux.so, can find them at run
time.

When you're linking amsr2_processor_rt, try adding the following flags to the
compiler invocation that actually creates the executable:

    -Wl,-rpath  -Wl,/usr/local/lib

to actually store the location of the shared library in the executable.

You .bashrc script gets invoked when you run a subshell or login, but not
when you directly invoke an executable binary, so the dynamic linker may
not get the value of LD_LIBRARY_PATH set in .bashrc.  You could test this
by setting LD_LIBRARY_PATH when you invioke the program, such as

  LD_LIBRARY_PATH=/usr/local/lib ./amsr2_processor_rt

but that's inconvenient and should be unnecessary if you use the linker
flags -Wl,-rpath -Wl,/usr/local/lib mentioned above.

You could also add /usr/local/lib to /etc/ld.so.conf, but that could be a
security problem, since libraries installed in /usr/local/lib tend to not
require as much scrutiny or testing as you might require.

> Thank you again for your help and patience!!

Your welcome!  Maybe other users will benefit from these answers when they
encounter similar problems.

--Russ


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



Ticket Details
===================
Ticket ID: QYP-982325
Department: Support netCDF
Priority: Normal
Status: Closed