From NWChem
Viewed 340 times, With a total of 4 Posts
|
|
|
Just Got Here
Threads 1
Posts 4
|
|
| 3:47:19 PM PDT - Tue, Apr 10th 2012 |
|
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 1
Posts 49
|
|
| 12:06:41 PM PDT - Wed, Apr 11th 2012 |
|
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
|
|
|
|
|
|
Just Got Here
Threads 1
Posts 4
|
|
| 1:35:19 PM PDT - Wed, Apr 11th 2012 |
|
Quote:Gary Apr 11th 7:06 pmI 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 1
Posts 49
|
|
| 3:56:12 PM PDT - Wed, Apr 11th 2012 |
|
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
|
|
|
|
|
|
Just Got Here
Threads 1
Posts 4
|
|
| 1:37:38 PM PDT - Thu, Apr 12th 2012 |
|
Thanks a lot. I must confess that I did no try the new version. It's working now.
Regards,
Rafael
|
|
|
AWC's:
2.5.10 MediaWiki - Stand Alone Forum Extension
Forum theme style by: AWC
