Library problem on OpenSUSE 12.1

From NWChem

Viewed 4530 times, With a total of 4 Posts
Jump to: navigation, search

Clicked A Few Times
Threads 2
Posts 10
After installing install_ecce.v6.3.rhel5-gcc4.1.2-m64.csh the execution of nwchem shows the following error message:

ecce-v6.3/apps/rhel5-gcc4.1.2-m64/3rdparty/nwchem/bin/nwchem: error while loading shared libraries: libgfortran.so.1: cannot open shared object file: No such file or directory

The OS in opensuse 12.1 64bits which uses gcc 4.6.2 and libgfortran.so.3.0.0. Symlinking libgfortran.so.1 to libgfortran.so.3.0.0 triggers the message:

symbol lookup error: /home/rafapa/Downloads/ECCE/ecce-v6.3/apps/rhel5-gcc4.1.2-m64/3rdparty/nwchem/bin/nwchem: undefined symbol: _gfortran_set_std

The safest thing is to download nwchem and install it from sources?

Thanks a lot

Dr. Rafael R. Pappalardo
Dept. Quimica Fisica, Fac. de Quimica,
Univ. of Seville (Spain)

Gets Around
Threads 2
Posts 82
I found this shared library omission over the weekend and updated the ECCE distributions (both binary and source code) to fix this. You can just download and install the latest ECCE 6.3 binary distribution (the latest distributions overwrote the original ones). ECCE only distributes binary distributions of NWChem even with our source code ECCE distribution so in this case building from source wouldn't help. Of course building NWChem from source code from the NWChem source code distribution and then registering that with ECCE would be the other solution.

Regards,
Gary Black

Clicked A Few Times
Threads 2
Posts 10
Quote:Gary Apr 11th 7:06 pm
I found this shared library omission over the weekend and updated the ECCE distributions (both binary and source code) to fix this. You can just download and install the latest ECCE 6.3 binary distribution (the latest distributions overwrote the original ones). ECCE only distributes binary distributions of NWChem even with our source code ECCE distribution so in this case building from source wouldn't help. Of course building NWChem from source code from the NWChem source code distribution and then registering that with ECCE would be the other solution.

Regards,
Gary Black


Dear Gary,
I have redownloaded from emsl.pnl.gov both
102101890 ecce-v6.3-src.tar.bz2
and
65419264 install_ecce.v6.3.rhel5-gcc4.1.2-m64.csh

There is a nwchem executable ininstall_ecce.v6.3.rhel5-gcc4.1.2-m64.csh :
68534153 ecce-v6.3/apps/rhel5-gcc4.1.2-m64/3rdparty/nwchem/bin/nwchem

the ldd command reports

       linux-vdso.so.1 =>  (0x00007fff754f9000)
libgfortran.so.1 => not found
libm.so.6 => /lib64/libm.so.6 (0x00002b2c4fd9b000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b2c4fff2000)
libc.so.6 => /lib64/libc.so.6 (0x00002b2c50208000)
/lib64/ld-linux-x86-64.so.2 (0x00002b2c4fb78000)

After untarring nwchem-6.1-binary-rhel5-gcc4.1.2-m64.tar.bz2 which is inside ecce-v6.3-src.tar.bz2
the nwchem executable is

68534153 Mar 30 21:05 bin/nwchem
and ldd reports is the same.
Something strange is the date of the nwchem executable.

Thank you for the help

Rafael

Gets Around
Threads 2
Posts 82
Rafael,

A simple ldd command will not find libgfortran.so.1 because $LD_LIBRARY_PATH is not set. You should see a lib directory that is parallel to the 3rdparty/nwchem/bin directory in the directory structure (i.e. 3rdparty/nwchem/lib). If you don't have that directory then you have the original ECCE 6.3 distribution. If you do have the directory then you have the proper updated ECCE 6.3 distribution. In that lib directory you will see just the libgfortran.so.1.

The trick is that our ECCE job submit script sets $LD_LIBRARY_PATH so that it can find the shared library. Having to use $LD_LIBRARY_PATH is pretty ugly in this day and age. But since I didn't want to start changing how NWChem is built, I just took the path of least resistance.

ECCE happens to use the -rpath directive when linking executables as a better alternative. That's how ECCE apps find the ECCE shared libs without having to set $LD_LIBRARY_PATH (and having potential side effects of non-ECCE applications picking up the wrong shared libraries for them). We use relative paths with -rpath and that makes ECCE easily relocatable when installed. All ECCE apps are started from the bin directory where they are installed. That means the path to shared libs is "../lib" for the ECCE shared libs and for the third party software it is more like ../3rdparty/wxwidgets/lib, ../3rdparty/xerces/lib, and ../3rdparty/system/lib, etc.

Anyway, if you ignore your ldd output and just try to run an NWChem job launched from ECCE, you'll be OK. If you want to use the ECCE built NWChem executable outside of ECCE then my suggestion is to run a single job from ECCE and take a look at the submit__* script that ECCE creates in the calculation run directory (you can create an xterm in that directory from the Organizer Run Mgmt menu) for an example of how to run it.

I'm sure there is a build directive for NWChem to create a statically linked executable to avoid these subtleties. In fact I remember with the NWChem 6.0 binary distributions that the NWChem team created they had static exectuables. That makes a lot of sense with a single monolithic application like NWChem, but not for ECCE as a suite of applications that share so much underlying code in libraries.

Regards,
Gary

Clicked A Few Times
Threads 2
Posts 10
Thanks a lot. I must confess that I did no try the new version. It's working now.

Regards,

Rafael


Forum >> ECCE: Extensible Computational Chemistry Environment >> General ECCE Topics



Who's here now Members 0 Guests 0 Bots/Crawler 1


AWC's: 2.5.10 MediaWiki - Stand Alone Forum Extension
Forum theme style by: AWC