Christof Koehler
2017-04-07 17:11:50 UTC
Hello everybody,
we are trying to build an appilcation with specific C++
requirements and for some reason we get the "wrong" libstdc++ library in
the end. At the moment the working hypothesis is that this might be
related to our OpenMPI built. I will try to explain below.
The application, which is C++/python, would like to have a compiler
which implements the C++14 standard. The system compiler on our cluster is
gcc 4.8.5 (Centos7) which is too old. We have a seperate gcc 6.3
installation which is available as a module and appears to be working
well, although I never tested C++ explicitely until now.
After loading the gcc 6.3 module I usually build my OpenMPI simply like this
./configure FFLAGS="-O1" CFLAGS="-O1" FCFLAGS="-O1" CXXFLAGS="-O1"
--with-psm2 --with-tm --with-hwloc=internal --enable-static
--enable-orterun-prefix-by-default
assuming that configure figures out the "right" compiler which I thought
it does based on observing
mpicc -v
Using built-in specs.
COLLECT_GCC=/cluster/comp/gcc/6.3.0/bin/gcc
COLLECT_LTO_WRAPPER=/cluster/comp/gcc/6.3.0/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-6.3.0/configure --prefix=/cluster/comp/gcc/6.3.0 --disable-multilib
Thread model: posix
gcc version 6.3.0 (GCC)
After that we build mpi4py (which as far as I can see is pure C
and not C++) with loaded gcc 6.3 and OpenMPI modules. Checking
the dynamic libraries of mpi4py with ldd we see
# ldd ./build/lib.linux-x86_64-2.7/mpi4py/MPI.so|grep libstdc
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002ab8b0c0b000)
which is obviously the systems (gcc 4.8.5) libstdc++, and that although
# echo $LD_LIBRARY_PATH
/cluster/comp/gcc/6.3.0/lib64:/cluster/comp/gcc/6.3.0/lib:/cluster/mpi/openmpi/2.0.2/gcc62/lib:/cluster/mpi/openmpi/2.0.2/gcc63/lib
On top, all OpenMPI libraries when checked with ldd (gcc 6.3 module
still loaded) reference the /usr/lib64/libstdc++.so.6 and not
/cluster/comp/gcc/6.3.0/lib64/libstdc++.so.6 which leads to the idea
that the OpenMPI installation might be the reason we have the
/usr/lib64/libstdc++.so.6 dependency in the mpi4py libraries as well.
What we would like to have is that libstdc++.so.6 resolves to the
libstdc++ provided by the gcc 6.3 compiler for the mpi4py, which would be
available in its installation directory, i.e. /cluster/comp/gcc/6.3.0/lib64/libstdc++.so.6.
So, am I missing options in my OpenMPI build ? Should I explicitely do a
./configure CC=/cluster/comp/gcc/6.3.0/bin/gcc CXX=/cluster/comp/gcc/6.3.0/bin/g++ ...
or similar ? Am I building it correctly with a gcc contained in a
separate module anyway ? Or do we have a problem with our ld configuration ?
Best Regards
Christof
we are trying to build an appilcation with specific C++
requirements and for some reason we get the "wrong" libstdc++ library in
the end. At the moment the working hypothesis is that this might be
related to our OpenMPI built. I will try to explain below.
The application, which is C++/python, would like to have a compiler
which implements the C++14 standard. The system compiler on our cluster is
gcc 4.8.5 (Centos7) which is too old. We have a seperate gcc 6.3
installation which is available as a module and appears to be working
well, although I never tested C++ explicitely until now.
After loading the gcc 6.3 module I usually build my OpenMPI simply like this
./configure FFLAGS="-O1" CFLAGS="-O1" FCFLAGS="-O1" CXXFLAGS="-O1"
--with-psm2 --with-tm --with-hwloc=internal --enable-static
--enable-orterun-prefix-by-default
assuming that configure figures out the "right" compiler which I thought
it does based on observing
mpicc -v
Using built-in specs.
COLLECT_GCC=/cluster/comp/gcc/6.3.0/bin/gcc
COLLECT_LTO_WRAPPER=/cluster/comp/gcc/6.3.0/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-6.3.0/configure --prefix=/cluster/comp/gcc/6.3.0 --disable-multilib
Thread model: posix
gcc version 6.3.0 (GCC)
After that we build mpi4py (which as far as I can see is pure C
and not C++) with loaded gcc 6.3 and OpenMPI modules. Checking
the dynamic libraries of mpi4py with ldd we see
# ldd ./build/lib.linux-x86_64-2.7/mpi4py/MPI.so|grep libstdc
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002ab8b0c0b000)
which is obviously the systems (gcc 4.8.5) libstdc++, and that although
# echo $LD_LIBRARY_PATH
/cluster/comp/gcc/6.3.0/lib64:/cluster/comp/gcc/6.3.0/lib:/cluster/mpi/openmpi/2.0.2/gcc62/lib:/cluster/mpi/openmpi/2.0.2/gcc63/lib
On top, all OpenMPI libraries when checked with ldd (gcc 6.3 module
still loaded) reference the /usr/lib64/libstdc++.so.6 and not
/cluster/comp/gcc/6.3.0/lib64/libstdc++.so.6 which leads to the idea
that the OpenMPI installation might be the reason we have the
/usr/lib64/libstdc++.so.6 dependency in the mpi4py libraries as well.
What we would like to have is that libstdc++.so.6 resolves to the
libstdc++ provided by the gcc 6.3 compiler for the mpi4py, which would be
available in its installation directory, i.e. /cluster/comp/gcc/6.3.0/lib64/libstdc++.so.6.
So, am I missing options in my OpenMPI build ? Should I explicitely do a
./configure CC=/cluster/comp/gcc/6.3.0/bin/gcc CXX=/cluster/comp/gcc/6.3.0/bin/g++ ...
or similar ? Am I building it correctly with a gcc contained in a
separate module anyway ? Or do we have a problem with our ld configuration ?
Best Regards
Christof