- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
summary: code which is known to build on 64-bit RHEL with Intel 11 compilers is failing to build on a particular cluster, with the error
> /ifs1/opt/intel-11.1/fortran_11.1.056/bin/intel64/fortcom: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
I lack admin rights on the cluster on which I want this to run, but would appreciate fix advice which I could relay to the admins.
details:
I am attempting to build CMAQ, an air-quality model widely used by the US Environmental Protection Agency (et al), on topsail, a Research Computing cluster @ UNC-Chapel Hill:
https://help.unc.edu/6214
> Login node : topsail.unc.edu 8 CPUs @ 2.3 GHz Intel EM64T with 2x4M
> L2 cache (Model E5345/Clovertown), 12 GB memory
> Compute nodes: 520 blade servers, each with 2 quad-core 2.3 GHz
> Intel EM64T processors, 2x4M L2 cache (Model E5345/Clovertown), and
> 12 GB memory[, managed by LSF.]
topsail nodes run RHEL 5, managed by LSF: `uname -imprv' on the compute nodes give
> 2.6.18-128.7.1.el5 #1 SMP Wed Aug 19 04:00:49 EDT 2009 x86_64 x86_64 x86_64
CMAQ builds widely in part because it supplies its own build scripts. I'm trying to run one (scripts/stenex/bldit.se.Linux), which first checks out fortran sources from a CVS repository, then compiles them. It's checking out without problem, but each compile fails like
> /usr/mpi/intel/mvapich-1.1.0/bin/mpif90 -extend_source 132 -cm -w95 -c -O2 -I/usr/mpi/intel/mvapich-1.1.0/include se_comm_info_ext.f
> /ifs1/opt/intel-11.1/fortran/bin/intel64/fortcom: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
> ifort: error #10273: Fatal error in /ifs1/opt/intel-11.1/fortran/bin/intel64/fortcom, terminated by 0x7f
I note a previous forum post:
http://software.intel.com/en-us/forums/showthread.php?t=61976
> Kevin Davis (Intel) November 19, 2008 9:46 AM PST
> Re: problem with libstdc++.so.5 using intel fortran compiler 11.0
> The Intel 64 compiler in the 11.0 release is a native 64-bit
> executable and requires /usr/lib64/libstdc++.so.5
Unfortunately on the compute nodes I am currently seeing only the 32-bit versions:
[tr@topsail-login1 ~]$ bsub -q int -Ip ls -al /usr/lib/libstdc++.so.5
...
lrwxrwxrwx 1 root root 18 Feb 23 21:12 /usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.7
[tr@topsail-login1 ~]$ bsub -q int -Ip ls -al /usr/lib/libstdc++.so.5.0.7
...
-rwxr-xr-x 1 root root 733488 Dec 1 2004 /usr/lib/libstdc++.so.5.0.7
[tr@topsail-login1 ~]$ bsub -q int -Ip ls -al /usr/lib64/libstdc++.so.5
...
ls: /usr/lib64/libstdc++.so.5: No such file or directory
So I'm assuming the lack of the 64-bit libstdc++.so.5 is causing the compile problem. Does that sound correct? If so, your assistance with convincing/helping my admins to fix it is appreciated. If not, please advise me regarding the actual problem.
TIA, Tom Roche
> /ifs1/opt/intel-11.1/fortran_11.1.056/bin/intel64/fortcom: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
I lack admin rights on the cluster on which I want this to run, but would appreciate fix advice which I could relay to the admins.
details:
I am attempting to build CMAQ, an air-quality model widely used by the US Environmental Protection Agency (et al), on topsail, a Research Computing cluster @ UNC-Chapel Hill:
https://help.unc.edu/6214
> Login node : topsail.unc.edu 8 CPUs @ 2.3 GHz Intel EM64T with 2x4M
> L2 cache (Model E5345/Clovertown), 12 GB memory
> Compute nodes: 520 blade servers, each with 2 quad-core 2.3 GHz
> Intel EM64T processors, 2x4M L2 cache (Model E5345/Clovertown), and
> 12 GB memory[, managed by LSF.]
topsail nodes run RHEL 5, managed by LSF: `uname -imprv' on the compute nodes give
> 2.6.18-128.7.1.el5 #1 SMP Wed Aug 19 04:00:49 EDT 2009 x86_64 x86_64 x86_64
CMAQ builds widely in part because it supplies its own build scripts. I'm trying to run one (scripts/stenex/bldit.se.Linux), which first checks out fortran sources from a CVS repository, then compiles them. It's checking out without problem, but each compile fails like
> /usr/mpi/intel/mvapich-1.1.0/bin/mpif90 -extend_source 132 -cm -w95 -c -O2 -I/usr/mpi/intel/mvapich-1.1.0/include se_comm_info_ext.f
> /ifs1/opt/intel-11.1/fortran/bin/intel64/fortcom: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
> ifort: error #10273: Fatal error in /ifs1/opt/intel-11.1/fortran/bin/intel64/fortcom, terminated by 0x7f
I note a previous forum post:
http://software.intel.com/en-us/forums/showthread.php?t=61976
> Kevin Davis (Intel) November 19, 2008 9:46 AM PST
> Re: problem with libstdc++.so.5 using intel fortran compiler 11.0
> The Intel 64 compiler in the 11.0 release is a native 64-bit
> executable and requires /usr/lib64/libstdc++.so.5
Unfortunately on the compute nodes I am currently seeing only the 32-bit versions:
[tr@topsail-login1 ~]$ bsub -q int -Ip ls -al /usr/lib/libstdc++.so.5
...
lrwxrwxrwx 1 root root 18 Feb 23 21:12 /usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.7
[tr@topsail-login1 ~]$ bsub -q int -Ip ls -al /usr/lib/libstdc++.so.5.0.7
...
-rwxr-xr-x 1 root root 733488 Dec 1 2004 /usr/lib/libstdc++.so.5.0.7
[tr@topsail-login1 ~]$ bsub -q int -Ip ls -al /usr/lib64/libstdc++.so.5
...
ls: /usr/lib64/libstdc++.so.5: No such file or directory
So I'm assuming the lack of the 64-bit libstdc++.so.5 is causing the compile problem. Does that sound correct? If so, your assistance with convincing/helping my admins to fix it is appreciated. If not, please advise me regarding the actual problem.
TIA, Tom Roche
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tom,
You are spot-on: the compute nodes need the 64 bit version of libstdc++.so.5.
For your admins, the easiest fix is to simply copy that file from the login/head node out to each of the compute nodes. If they use a master node image and diskless boot it will be a cake walk.
ron
You are spot-on: the compute nodes need the 64 bit version of libstdc++.so.5.
For your admins, the easiest fix is to simply copy that file from the login/head node out to each of the compute nodes. If they use a master node image and diskless boot it will be a cake walk.
ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting Ronald W. Green (Intel)
Tom,
the compute nodes need the 64 bit version of libstdc++.so.5.For your admins, the easiest fix is to simply copy that file from the login/head node out to each of the compute nodes.
the compute nodes need the 64 bit version of libstdc++.so.5.For your admins, the easiest fix is to simply copy that file from the login/head node out to each of the compute nodes.
> [noted] the login node has both the 32-bit and the 64-bit version of this
> library, but the compute nodes are lacking the 64bit version of this
> library. I have manually updated the nodes to include the RPM
> compat-libstdc++-33-3.2.3-61.x86_64.rpm
That also solved the problem.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page