On Sat, 4 Dec 2004 07:49:24 -0500, Jeff Squyres <jsquyres_at_[hidden]> wrote:
> I'm joining this thread a little late -- is there a reason you're using
> -static? According to the error messages, not using that may fix the
> problem...?
>
>
Yes. This is my situation. I have access to two machines (let's say 1
and 2). machine 2 is slower compared to machine 1. So I usually
develop (compile/debug) the code on machine 1 and when everything is
fine, I just transfer the a.out (executable) to machine 2 and run it
there.
Machine 1 is fedora core1
$rpm -qa glibc gcc
glibc-2.3.2-101
gcc-3.3.2-1
Machine 2 is redhat linux 8.
$rpm -qa glibc gcc
glibc-2.2.93-5
gcc-3.2-7
situation 1:
lam-mpi built on machine1 without the static option and using
icc8.1,ifort8.1, icpc8.1. In this case when the final execuatable
(a.out) is run on machine 2, there is a runtime error saying
$mpirun -np 4 a.out
a.out: /lib/i686/libc.so.6: version `GLIBC_2.3.2' not found (required
by a.out)
a.out: /lib/i686/libc.so.6: version `GLIBC_2.3.2' not found (required
by a.out)
Tim Prince on comp.lang.fortran pointed out that this is due to the
fact that when a.out is built on machine 1, it is linking with
glibc_2.3.2 libraries and it could not find those libraries on
machine 2. More details can be found at
http://groups.google.com/groups?dq=&hl=en&lr=&safe=off&threadm=coroni%24h47%241%40news01.cit.cornell.edu&prev=/groups%3Fq%3Dcomp.lang.fortran%26hl%3Den%26btnG%3DGoogle%2BSearch
situation2:
Because of the glibc conflicts, I decided to build everything with the
-static option.This seem to work fine except for the warnings (given
in my second post).
I am not an expert in compiling and building libraries, but what
worries me is "why should the libraries compiled exclusively with
(icc, ifort) depend on gcc versions?" Does that mean that intel
compilers depend on gcc? I dont know for sure...
I did further research on this and finally found the cause of all
these problems is libc.so.6 file. When I compiled the helloworld.f90
on "machine 1" and do ldd on the a.out
machine1$ldd a.out
libaio.so.1 => /usr/lib/libaio.so.1 (0x4001d000)
libutil.so.1 => /lib/libutil.so.1 (0x4f4be000)
libdl.so.2 => /lib/libdl.so.2 (0x4e8e7000)
libm.so.6 => /lib/i686/libm.so.6 (0x4e6d6000)
libcxa.so.5 => /opt/intel_cc_80/lib/libcxa.so.5 (0x4001f000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4e393000)
libunwind.so.5 => /opt/intel_cc_80/lib/libunwind.so.5 (0x40047000)
libc.so.6 => /lib/i686/libc.so.6 (0x4e71f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00af7000)
machine1$ls -al /lib/i686/libc.so.6
lrwxrwxrwx 1 root root 13 Mar 7 2004
/lib/i686/libc.so.6 -> libc-2.3.2.so
machine2$ldd a.out
./a.out: /lib/i686/libc.so.6: version `GLIBC_2.3.2' not found
(required by ./a.out)
libaio.so.1 => /usr/lib/libaio.so.1 (0x4002c000)
libutil.so.1 => /lib/libutil.so.1 (0x4002f000)
libdl.so.2 => /lib/libdl.so.2 (0x40032000)
libm.so.6 => /lib/i686/libm.so.6 (0x40035000)
libcxa.so.5 => /opt/intel_cc_80/lib/libcxa.so.5 (0x40057000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4007e000)
libunwind.so.5 => /opt/intel_cc_80/lib/libunwind.so.5 (0x400ae000)
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
libredhat-kernel.so.1 => /lib/libredhat-kernel.so.1 (0x400b5000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
machine2$ls -al /lib/i686/libc.so.6
lrwxrwxrwx 1 root root 14 Feb 24 2003
/lib/i686/libc.so.6 -> libc-2.2.93.so
As you can see the libc.so.6 on both machines point to different
libc-x.x.xx.so files. Hence the problem with the shared libraries.
I tried to see if intel provides a libc.so.6
machine1$find /opt/intel_cc_80/ -iname '*libc*'
/opt/intel_cc_80/lib/libcprts.a
/opt/intel_cc_80/lib/libcprts.so
/opt/intel_cc_80/lib/libcprts.so.5
/opt/intel_cc_80/lib/libcxa.a
/opt/intel_cc_80/lib/libcxa.so
/opt/intel_cc_80/lib/libcxa.so.5
/opt/intel_cc_80/lib/libcxaguard.a
/opt/intel_cc_80/lib/libcxaguard.so
/opt/intel_cc_80/lib/libcxaguard.so.5
So there is no libc.so.6 offered by intel. I have no idea why a.out
should even depend on it in the first place.
In case there is something wrong with my environment
machine1$echo $LD_LIBRARY_PATH
/opt/intel_cc_80/lib:/opt/intel_fc_80/lib
machine2$echo $LD_LIBRARY_PATH
/opt/intel_cc_80/lib:/opt/intel_fc_80/lib
Any comments/suggestions are most welcome.
raju
--
Kamaraju S Kusumanchi
Cornell University
http://people.cornell.edu/pages/kk288/
http://groups.yahoo.com/group/flumech/
|
