Since I’m on a mac (and don’t have access to a Linux machine at the moment) things are a little different. However, my rism3d.snglpnt (a NAB executable) is correctly linked
$ otool -L bin/rism3d.snglpnt
bin/rism3d.snglpnt:
/Users/tluchko/projects/amber/master/lib/libfftw3.3.dylib (compatibility version 7.0.0, current version 7.0.0)
/Users/tluchko/projects/amber/master/lib/libnetcdf.7.dylib (compatibility version 10.0.0, current version 10.0.0)
/opt/local/lib/libgcc/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
/opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
and there is nothing of significance on my DYLD_LIBRARY_PATH (equivalent of LD_LIBRARY_PATH)
$ echo $DYLD_LIBRARY_PATH
/usr/local/cuda/lib:
(the directory doesn't exist)
FWIW, I ran configure with
./configure -noX11 -nomtkpp -macAccelerate gnu
I’m not sure why this is coming up now. Checking the git logs, I don’t see anything obvious. sff/ and nab/ directories haven’t been touched since November. configure2 hasn’t had a NetCDF change since November and the NetCDF libraries are basically hasn’t been touched since November.
Tyler
On Jan 28, 2014, at 10:47 PM, Timothy Giese <timothyjgiese.gmail.com> wrote:
> I can reproduce this.
>
> There are 3 possible solutions:
>
> (1) Someplace (I don't know where yet - I haven't found it in nab.c) there
> is a -lnetcdf
> but that link line should have a -static so that it links to the .a instead
> of the .so
>
> or
>
> (2) export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$AMBERHOME/lib
> before you run the executable
>
> or
>
> (3) Find the -lnetcdf flag and replace it with the full path
> $AMBERHOME/lib/libnetcdf.so (or .a)
>
>
> [giese.buzet nab]$ ../../bin/nab -o duplex duplex.nab
>
> I see duplex depends on libnetcdf, but that's not in my ld path
>
> [giese.buzet nab]$ ldd duplex
> linux-vdso.so.1 => (0x00007fffe13ff000)
> libfftw3.so.3 => /usr/lib64/libfftw3.so.3 (0x0000003003400000)
> libnetcdf.so.7 => not found <--------------
> libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003f14400000)
> libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007fd2cae8e000)
> libm.so.6 => /lib64/libm.so.6 (0x0000003f28400000)
> libc.so.6 => /lib64/libc.so.6 (0x0000003f13c00000)
> /lib64/ld-linux-x86-64.so.2 (0x0000003f13800000)
> libquadmath.so.0 => /usr/lib64/libquadmath.so.0 (0x0000003902c00000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003902800000)
>
> Of course, it doesn't run
>
> [giese.buzet nab]$ ./duplex
> ./duplex: error while loading shared libraries: libnetcdf.so.7: cannot open
> shared object file: No such file or directory
>
> Let me add that directory to my ld path
>
> [giese.buzet nab]$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$AMBERHOME/lib
>
>
> [giese.buzet nab]$ ./duplex
> (ok - it runs)
>
> When you link to a dynamic library without specifying the full path, it
> only marks the name of the library to be searched for within the executable.
>
> When you run the executable, it searches the directories in your ld search
> paths...
> LD_LIBRARY_PATH
> /etc/ld.so.conf
> /etc/ld.so.conf.d/*
> ...for the library at run time.
>
> If you link to a shared library with the full path, then it (at least in my
> experience on the machines I've run on) it stores the full path of the
> shared library within the executable so that the library does not need to
> be within your ld path at runtime.
>
> Of course, linking to the static archive avoids these issues altogether.
>
>
>
> -Tim
>
>
>
>
>
> On Wed, Jan 29, 2014 at 12:12 AM, Ross Walker <ross.rosswalker.co.uk> wrote:
>
>> Hi All,
>>
>> Has anybody else seen issues with netcdf shared libraries?
>>
>> Latest git tree as of 9pm PST today.
>>
>> ./configure gnu
>> make -j8 install
>> make test
>>
>> cd leap/glycam && ./Run_tests.bash clean
>> cd nab && make -k test testrism
>> make[3]: Entering directory
>> `/cbio/jclab/home/rcw/amber/AmberTools/test/nab'
>> Running test to make dna duplex:
>>
>> ./duplex: error while loading shared libraries: libnetcdf.so.7: cannot
>> open shared object file: No such file or directory
>> ./Run.duplex: Program error
>> make[3]: *** [duplex_test] Error 1
>> Running test to computed 3DNA deformation energies:
>>
>> ./deform: error while loading shared libraries: libnetcdf.so.7: cannot
>> open shared object file: No such file or directory
>> ./Run.deform: Program error
>> make[3]: *** [deform_test] Error 1
>> Running Reflexive test:
>>
>> ./refl: error while loading shared libraries: libnetcdf.so.7: cannot open
>> shared object file: No such file or directory
>> ./Run.reflexive: Program error
>> make[3]: *** [reflexive_test] Error 1
>> Running test of sub() and gsub()
>>
>>
>> ... etc ...
>>
>> does this for ALL the rism tests and then everything looks good
>>
>> ./Run.rism_xmin: Program error
>> make[3]: *** [rism_xmin] Error 1
>> make[3]: Target `testrism' not remade because of errors.
>> make[3]: Leaving directory `/cbio/jclab/home/rcw/amber/AmberTools/test/nab'
>> make[2]: *** [test.nab] Error 2
>> cd cpptraj && make -k test
>> make[3]: Entering directory
>> `/cbio/jclab/home/rcw/amber/AmberTools/test/cpptraj'
>> make test.main
>> make[4]: Entering directory
>> `/cbio/jclab/home/rcw/amber/AmberTools/test/cpptraj'
>> **************************************************************
>> TEST: /cbio/jclab/home/rcw/amber/AmberTools/test/cpptraj/Test_General
>>
>> CPPTRAJ: General tests
>> diffing distance.dat.save with distance.dat
>> PASSED
>> ==============================================================
>> diffing rmsd.dat.save with rmsd.dat
>>
>> ... etc ...
>>
>>
>> Seems like rism is relying on system netcdf for some reason? - Or
>> something else is wrong.
>>
>> All the best
>> Ross
>>
>> /\
>> \/
>> |\oss Walker
>>
>> ---------------------------------------------------------
>> | Associate Research Professor |
>> | San Diego Supercomputer Center |
>> | Adjunct Associate Professor |
>> | Dept. of Chemistry and Biochemistry |
>> | University of California San Diego |
>> | NVIDIA Fellow |
>> | http://www.rosswalker.co.uk | http://www.wmd-lab.org |
>> | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
>> ---------------------------------------------------------
>>
>> Note: Electronic Mail is not secure, has no guarantee of delivery, may not
>> be read every day, and should not be used for urgent or sensitive issues.
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Jan 28 2014 - 23:30:02 PST
