non-standard path for libstdc++ in expand_instantiation

[Hecke Schrobsdorff]

Hi All,

I am (again) struggling to get deal.ii to compile on our cluster.
This time, my goal is a very basic variant of deal.ii without any external libraries but a non-standard gcc.
The cluster runs on SLES 11 SP1 thus has gcc-4.3.4 and I want to use a custom installation of gcc-4.7.2 because of C++11 features.

Unfortunately, the alternate directory for the corresponding libraries does not seem to reach the expand_instantiation script:

Scanning dependencies of target obj_opencascade.inst
[ 21%] Generating boundary_lib.inst
../../common/scripts/expand_instantiations: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ../../common/scripts/expand_instantiations)
make[2]: *** [source/opencascade/boundary_lib.inst] Error 1
make[1]: *** [source/opencascade/CMakeFiles/obj_opencascade.inst.dir/all] Error 2

My cmake command is

cmake  -DCMAKE_INSTALL_PREFIX=/usr/nld/deal.II-8.2.1.freya-gcc-4.7.2 -DDEAL_II_WITH_MPI=OFF -DDEAL_II_WITH_PETSC=OFF -DCMAKE_CXX_COMPILER=/usr/nld/gcc-4.7.2/bin/g++ -DLAPACK_DIR=/usr/nld/atlas-3.8.3_LAPACK.skadi/ -DBLAS_DIR=/usr/nld/atlas-3.8.3_LAPACK.skadi/ -DBLA_VENDOR=ATLAS  ..

The BLAS/LAPACK variables are set, because I noticed that cmake complains to not find LAPACK.
But even with the above cmake call, I get:

--   LAPACK_LIBRARIES: *** Required variable "_lapack_libraries" empty ***
--   LAPACK_LINKER_FLAGS:
-- Could NOT find LAPACK
-- DEAL_II_WITH_LAPACK has unmet external dependencies.

I have no idea if the LAPACK issue has something to do with the linking error for libstdc++.
The output looks like the dependency to LAPACK is not mandatory for compilation though.

Any help is appreciated!

thanks
      Hecke

[Wolfgang Bangerth]

Hecke,

> I am (again) struggling to get deal.ii to compile on our cluster.
> This time, my goal is a very basic variant of deal.ii without any external
> libraries but a non-standard gcc.
> The cluster runs on SLES 11 SP1 thus has gcc-4.3.4 and I want to use a custom
> installation of gcc-4.7.2 because of C++11 features.
>
> Unfortunately, the alternate directory for the corresponding libraries does
> not seem to reach the expand_instantiation script:
>
> |
> Scanningdependencies of target obj_opencascade.inst
> [21%]Generatingboundary_lib.inst
> ../../common/scripts/expand_instantiations:/usr/lib64/libstdc++.so.6:version
> `GLIBCXX_3.4.15' not found (required by
> ../../common/scripts/expand_instantiations)
> make[2]: *** [source/opencascade/boundary_lib.inst] Error 1
> make[1]: *** [source/opencascade/CMakeFiles/obj_opencascade.inst.dir/all] Error 2
> |
>
> My cmake command is
>
> |
> cmake
> -DCMAKE_INSTALL_PREFIX=/usr/nld/deal.II-8.2.1.freya-gcc-4.7.2-DDEAL_II_WITH_MPI=OFF
> -DDEAL_II_WITH_PETSC=OFF
> -DCMAKE_CXX_COMPILER=/usr/nld/gcc-4.7.2/bin/g++-DLAPACK_DIR=/usr/nld/atlas-3.8.3_LAPACK.skadi/-DBLAS_DIR=/usr/nld/atlas-3.8.3_LAPACK.skadi/-DBLA_VENDOR=ATLAS
> ..
> |

What is happening is that you tell cmake to use a specific compiler. This
allows you to compile the expend_instantiations.cc file and link it (because
the compiler knows where to find its compiler support libraries such as
libstdc++), but when you try to execute the program, this yields the error
message you see: the dynamic loader tries to execute your program, but because
it's part of the operating system, it no longer knows where the compiler
support libraries for 4.7.2 are located (it only knows that it's supposed to
load libstd++.so with version number 3.4.15), and fails.

To make work what you're trying to do, you need to not only select which
compiler to use, but also where to find these libraries. You do this by
setting the LD_LIBRARY_PATH environment variable. In your case, I would
suggest you put something like this into your .bashrc:

export PATH=/usr/nld/gcc-4.7.2/bin/:$PATH
export LD_LIBRARY_PATH=/usr/nld/gcc-4.7.2/lib/:$LD_LIBRARY_PATH

This requires you to *always* use this compiler, but that's likely what you
want anyway.

Best
W.



--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@math.tamu.edu
www: http://www.math.tamu.edu/~bangerth/

[Hecke Schrobsdorff]

Hi Wolfgang,

I am sorry to reach out with such simple problems, setting the LD_LIBRARY_PATH is pretty common in our cluster setup. But somehow I thought that setting the compiler for cmake will take care of everything for the compilation.

thanks a bunch!
    Hecke

[Wolfgang Bangerth]

On 07/01/2015 01:04 PM, Hecke Schrobsdorff wrote:
>
> I am sorry to reach out with such simple problems, setting the LD_LIBRARY_PATH
> is pretty common in our cluster setup. But somehow I thought that setting the
> compiler for cmake will take care of everything for the compilation.

There wasn't anything cmake could have done about this. The issue was that
when cmake executes a program (here, the expand_instantiations script) then it
calls the operating system's 'dynamic loader' which finds the necessary
libraries based on environment variables. cmake can't know where the compiler
support libraries are, and can't set the environment variables correctly.

One could argue that it's a flaw in operating system design that these paths
are not recorded in the executable itself by default (I actually think so).
But it is what it is -- if you choose a different compiler, you also need to
export the location of compiler support libraries via LD_LIBRARY_PATH :-(