Installation problems CentOS 6.8

Discussions on installation issues go here.
barry
Posts: 3
Joined: 13 Apr 2017, 19:32

Installation problems CentOS 6.8

Postby barry » 13 Apr 2017, 19:41

I am having problems with Ext.so. Some background: We are using CentOS 6.8. The system versions of gcc and perl are too old for
polymake, so I built newer versions. We use environment modules to control which version is then used. I used gcc 5.4 and perl 5.16.3.

Everything compiles fine, but when starting polymake, I get the error message:


swadmin@pleiades Ext]$ polymake
Can't load '/usr/public/polymake/3.0/lib/polymake/perlx/5.16.3/x86_64-linux-thread-multi/auto/Polymake/Ext/Ext.so'\
for module Polymake::Ext: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /usr/public/\
polymake/3.0/lib/polymake/perlx/5.16.3/x86_64-linux-thread-multi/auto/Polymake/Ext/Ext.so) at /usr/public/perl/5.1\
6.3/lib/DynaLoader.pm line 191.
at /usr/public/polymake/3.0/share/polymake/perllib/Polymake/Namespaces.pm line 17.
Compilation failed in require at /usr/public/polymake/3.0/share/polymake/perllib/Polymake/Namespaces.pm line 17.
BEGIN failed--compilation aborted at /usr/public/polymake/3.0/share/polymake/perllib/Polymake/Namespaces.pm line 1


I built polymake using the version of libstdc++ that is specific to my installation of gcc 5.4. However, the loader always wants to use /usr/lib64/libstdc++. I have set:

LD_LIBRARY_PATH=/usr/public/polymake/3.0/lib:/usr/public/perl/5.16.3/lib:/usr/public/gnu/gcc/5.4.0/lib64:/usr/public/gnu/gcc/5.4.0/lib:/usr/public/torque/lib

So, it should find libstdc++.so.6 in /usr/public/gnu/gcc/5.4.0/lib64. It doesn't, nor does it find any libraries there, instead finding them in /lib64 or /usr/lib64.


[swadmin@pleiades Ext]$ ldd Ext.so
./Ext.so: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ./Ext.so)
./Ext.so: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./Ext.so)
linux-vdso.so.1 => (0x00007ffc109a1000)
libmpfr.so.4 => /usr/public/gnu/gcc/5.4.0/lib/libmpfr.so.4 (0x00002ae7b25ea000)
libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00002ae7b2849000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ae7b2aa4000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00002ae7b2cc1000)
libz.so.1 => /lib64/libz.so.1 (0x00002ae7b3015000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002ae7b322b000)
libm.so.6 => /lib64/libm.so.6 (0x00002ae7b3531000)
libgomp.so.1 => /usr/lib64/libgomp.so.1 (0x00002ae7b37b6000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002ae7b39cb000)
libc.so.6 => /lib64/libc.so.6 (0x00002ae7b3be1000)
libgmp.so.10 => /usr/public/gnu/gcc/5.4.0/lib/libgmp.so.10 (0x00002ae7b3f76000)
/lib64/ld-linux-x86-64.so.2 (0x000000376dc00000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002ae7b41ea000)
librt.so.1 => /lib64/librt.so.1 (0x00002ae7b43ee000)


Note: libpolymake.so is able to find the correct version of libstdc++.so.6 (and other libraries)

swadmin@pleiades lib]$ ldd libpolymake.so
linux-vdso.so.1 => (0x00007ffd677e6000)
libmpfr.so.4 => /usr/public/gnu/gcc/5.4.0/lib/libmpfr.so.4 (0x00002ba42b6c1000)
libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00002ba42b93f000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ba42bb9a000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00002ba42bdb7000)
libz.so.1 => /lib64/libz.so.1 (0x00002ba42c10b000)
libperl.so => /usr/public/perl/5.16.3/lib/CORE/libperl.so (0x00002ba42c321000)
libstdc++.so.6 => /usr/public/gnu/gcc/5.4.0/lib64/libstdc++.so.6 (0x00002ba42c5a6000)
libm.so.6 => /lib64/libm.so.6 (0x00002ba42c935000)
libgomp.so.1 => /usr/public/gnu/gcc/5.4.0/lib64/libgomp.so.1 (0x00002ba42cbb9000)
libgcc_s.so.1 => /usr/public/gnu/gcc/5.4.0/lib64/libgcc_s.so.1 (0x00002ba42cdda000)
libc.so.6 => /lib64/libc.so.6 (0x00002ba42cff1000)
libgmp.so.10 => /usr/public/gnu/gcc/5.4.0/lib/libgmp.so.10 (0x00002ba42d385000)
/lib64/ld-linux-x86-64.so.2 (0x000000376dc00000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002ba42d5f9000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00002ba42d7fe000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002ba42da17000)
libutil.so.1 => /lib64/libutil.so.1 (0x00002ba42dc4e000)
librt.so.1 => /lib64/librt.so.1 (0x00002ba42de52000)
libfreebl3.so => /lib64/libfreebl3.so (0x00002ba42e05a000)


So, there is something with the way Ext.so was compiled that it doesn't see LD_LIBRARY_PATH to pick up the correct libstdc++.so.6.

****** Do you have suggestions on how to fix the problem? ********

Note. I am using polymake-3.0r2.

An Aside: I had problems compiling version 3.1 (with gcc 5.1, gcc 5.4, gcc 6.3), which is why I used version 3.0. I always get the following:

In file included from <command-line>:0:0:
/usr/public/polymake/sources/polymake-3.1gcc5.4/bundled/libnormaliz/apps/polytope/src/normaliz.cc: In function 'pm:
:RationalFunction<> polymake::polytope::{anonymous}::nmz_convert_HS(const libnormaliz::HilbertSeries&)':
/usr/public/polymake/sources/polymake-3.1gcc5.4/bundled/libnormaliz/apps/polytope/src/normaliz.cc:192:87: error: no
matching function for call to 'convert_to(pm::Vector<__gmp_expr<__mpz_struct [1], __mpz_struct [1]> >)'
UniPolynomial<> HSnum(convert_to<Integer>(Vector<mpz_class>(nmzHilb.getNum())),
^
In file included from /usr/public/polymake/sources/polymake-3.1gcc5.4/include/core/polymake/Integer.h:26:0,
from /usr/public/polymake/sources/polymake-3.1gcc5.4/include/core-wrappers/polymake/Integer.h:20,
from /usr/public/polymake/sources/polymake-3.1gcc5.4/bundled/libnormaliz/apps/polytope/src/normali
z.cc:22,
from <command-line>:0:
/usr/public/polymake/sources/polymake-3.1gcc5.4/include/core/polymake/internal/converters.h:164:8: note: candidate:
template<class Target, class Source> Target pm::convert_to(const Source&, typename std::enable_if<((pm::can_initia
lize<Source, Target>::value && ((! std::is_arithmetic<T>::value) || (! std::is_arithmetic<_Tp>::value))) && (! std:
:is_base_of<T1, T2>::value)), void**>::type)
Target convert_to(const Source& x,
^
/usr/public/polymake/sources/polymake-3.1gcc5.4/include/core/polymake/internal/converters.h:164:8: note: template
argument deduction/substitution failed:
/usr/public/polymake/sources/polymake-3.1gcc5.4/include/core/polymake/internal/converters.h: In substitution of 'te
mplate<class Target, class Source> Target pm::convert_to(const Source&, typename std::enable_if<((pm::can_initializ
e<Source, Target>::value && ((! std::is_arithmetic<T>::value) || (! std::is_arithmetic<_Tp>::value))) && (! std::is
_base_of<T1, T2>::value)), void**>::type) [with Target = pm::Integer; Source = pm::Vector<__gmp_expr<__mpz_struct [
1], __mpz_struct [1]> >]':
/usr/public/polymake/sources/polymake-3.1gcc5.4/bundled/libnormaliz/apps/polytope/src/normaliz.cc:192:87: require
d from here
/usr/public/polymake/sources/polymake-3.1gcc5.4/include/core/polymake/internal/converters.h:164:8: error: no type n
amed 'type' in 'struct std::enable_if<false, void**>'

Thank you

Barry

User avatar
gawrilow
Main Author
Posts: 423
Joined: 25 Dec 2010, 17:40

Re: Installation problems CentOS 6.8

Postby gawrilow » 18 Apr 2017, 01:42

On the first problem: Ext.so is not a "normal" shared library despite of its suffix '.so' . It's a dynamic module loaded with dlopen() some time after the program (perl interpreter) start; however, LD_LIBRARY_PATH is only consulted by dynamic loader for shared libraries required immediately at the program start. This is not a specific problem of polymake but a common mess for everybody using a manually built gcc with shared libraries installed at a non-standard location. When you link any C++program compiled with your custom gcc, add an option -Wl,-rpath,/path/where/your/custom/libstdc++/dwells . If you want to fix this for polymake only, you can set this as a configure script option LDFLAGS=... . If you want to use this compiler for other projects as well and have this option applied automatically, you can create a specs file (gcc -dumpspecs) and insert the option into the *link command, in a dynamic linking clause.

The second problem (failing to compile the libnormaliz extension) looks like you've picked a strange version of GMP C++ wrappers (libgmpxx), either too old or too new for polymake. Have you installed it yourself or does it come from a host system RPM package; does it match the version of libgmp?

blorenz
Developer
Posts: 139
Joined: 10 Jan 2011, 17:21

Re: Installation problems CentOS 6.8

Postby blorenz » 18 Apr 2017, 11:03

A few comments on the required versions:

polymake 3.0 should build with all gcc versions starting from 4.2 (but might have issues with very new ones), the minimal perl version is 5.10.0 (see https://polymake.org/doku.php/howto/install_legacy ), both should be satisfied in CentOS 6.

The compilation error for the normaliz extensions might also be caused by mixing a rather old gmp version (< 5.1) with a quite new gcc version. One workaround would be to disable this extension by passing

Code: Select all

--without-libnormaliz
to the configure script.

barry
Posts: 3
Joined: 13 Apr 2017, 19:32

Re: Installation problems CentOS 6.8

Postby barry » 18 Apr 2017, 18:30

Thank you for the suggestions. I now have 3.0 working

I added the rpath to LDFLAGS= in the configure step, which solved the
problem in 3.0 I also added --with-gmp= and --with-mpfr in the
configure step. I thought I had specified the location of the
libraries and include files in the LDFLAGS, LD_LIBRARY_PATH, CFLAGS,
CXXFLAGS corresponding to the version of gcc that I was using, but it
seems the old system ones (installed via rpms) were being used. This
didn't seem to cause problems for 3.0, but I now know I am using the
correct versions of gmp and mpfr. I used gcc version 5.4.0 and perl
5.16.3.

For 3.1. I am still getting the same error in my original post, even
with --with-gmp= and --with-mpfr that corresponds to gcc 5.4.0.
I think we are fine with 3.0. If you want to pursue this, I would be
happy to help.

Barry

barry
Posts: 3
Joined: 13 Apr 2017, 19:32

Re: Installation problems CentOS 6.8

Postby barry » 18 Apr 2017, 19:48

Version 3.1 is now working. I recompiled gmp 6.0. I had forgotten to add:

--enable-cxx

Barry

User avatar
gawrilow
Main Author
Posts: 423
Joined: 25 Dec 2010, 17:40

Re: Installation problems CentOS 6.8

Postby gawrilow » 18 Apr 2017, 23:25

Thanks for the positive feedback!

I guess, we should add a version coherence check for gmp and gmpxx in our magic configuration script.


Return to “Installing polymake”