Summary: | [sage-on-gentoo] sci-mathematics/singular-3.1.7_p1-r4 - /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Juergen Rose <rose> |
Component: | Current packages | Assignee: | Thomas Kahle (RETIRED) <tomka> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dschridde+gentoobugs, frp.bissey, sci-mathematics |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Juergen Rose
2016-01-22 17:47:00 UTC
Now the singular-3.1.3.2-python.patch fails: root@impala:/usr/src/linux(75)# MAKEOPTS=-j1 emerge -v1 singular These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sci-mathematics/singular-3.1.7_p1-r4::sage-on-gentoo USE="boost doc emacs examples python readline -flint {-test}" PYTHON_TARGETS="python2_7" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict: sci-mathematics/singular:0 (sci-mathematics/singular-4.0.2:0/0::gentoo, ebuild scheduled for merge) conflicts with ~sci-mathematics/singular-3.1.7_p1 required by (sci-mathematics/sage-7.0:0/0::sage-on-gentoo, installed) ^ ^^^^^^^^ >>> Verifying ebuild manifests >>> Emerging (1 of 1) sci-mathematics/singular-3.1.7_p1-r4::sage-on-gentoo * Singular-3-1-7p1.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * Singular-3-1-7-share.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * Emacs version: 24.5.1 >>> Unpacking source... >>> Unpacking Singular-3-1-7p1.tar.gz to /var/tmp/portage/sci-mathematics/singular-3.1.7_p1-r4/work >>> Unpacking Singular-3-1-7-share.tar.gz to /var/tmp/portage/sci-mathematics/singular-3.1.7_p1-r4/work >>> Source unpacked in /var/tmp/portage/sci-mathematics/singular-3.1.7_p1-r4/work >>> Preparing source in /var/tmp/portage/sci-mathematics/singular-3.1.7_p1-r4/work/Singular-3-1-7 ... * Applying singular-3.1.0-gentoo.patch ... [ ok ] * Applying singular-3.1.0-emacs-22.patch ... [ ok ] * Applying singular-3.0.4.4-nostrip.patch ... [ ok ] * Applying singular-3.1.3.3-Minor.h.patch ... [ ok ] * Applying singular-3.1.7-flintconfig-r2.patch ... [ ok ] * Applying singular-3.1.7-implicit-template.patch ... [ ok ] * Applying singular-3.1.7-use_cxx_for_linking.patch ... [ ok ] * Applying singular-3.1.7-curring.patch ... [ ok ] * Applying singular-3.1.7-ntl8.patch ... [ ok ] * Applying singular-3.1.3.2-python.patch ... The text leading up to this was: -------------------------- |--- Singular/pyobject.cc.orig 2011-01-31 15:03:16.000000000 +0100 |+++ Singular/pyobject.cc 2011-08-24 17:22:57.000000000 +0200 -------------------------- No file to patch. Skipping patch. 3 out of 3 hunks ignored The text leading up to this was: -------------------------- |--- Singular/pyobject_setup.cc.orig 2011-02-10 19:15:30.000000000 +0100 |+++ Singular/pyobject_setup.cc 2011-08-24 17:23:55.000000000 +0200 -------------------------- No file to patch. Skipping patch. 1 out of 1 hunk ignored [ !! ] * ERROR: sci-mathematics/singular-3.1.7_p1-r4::sage-on-gentoo failed (prepare phase): * patch -p1 failed with /var/lib/layman/sage-on-gentoo/sci-mathematics/singular/files/singular-3.1.3.2-python.patch I have a /var/tmp/portage/sci-mathematics/singular-3.1.7_p1-r4/work/Singular-3-1-7/Singular/pyobject_setup.cc file: root@impala:/var/tmp/portage/sci-mathematics/singular-3.1.7_p1-r4(86)# find . -name pyobject_setup.cc ./work/Singular-3-1-7/Singular/pyobject_setup.cc And I have: root@impala:/var/tmp/portage/sci-mathematics/singular-3.1.7_p1-r4/work(122)# find . -name pyobject.cc ./Singular-3-1-7/Singular/pyobject.cc I can avoid the problem with the failing singular-3.1.3.2-python.patch by using a modified singular-3.1.3.2-python.patch and replacing the line use python && eapply "${FILESDIR}"/${PN}-3.1.3.2-python.patch by the line use python && epatch "${FILESDIR}"/${PN}-3.1.3.2-python.patch but then 'MAKEOPTS=-j1 emerge -v1 singular' fails again with the old error: x86_64-pc-linux-gnu-g++ -c algext.cc -Wall -I. -I.. -I. -I/var/tmp/portage/sci-mathematics/singular-3.1.7_p1-r4/work/Singular-3-1-7/build -I/var/tmp/portage/sci-mathematics/singular-3.1.7_p1-r4/work/Singular-3-1-7/build/include -DHAVE_CONFIG_H -march=amdfam10 -O2 -pipe -fPIC -o algext.o In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/atomic:38:0, from /usr/include/NTL/thread.h:10, from /usr/include/NTL/SmartPtr.h:7, from /usr/include/NTL/ZZ.h:21, from /usr/include/NTL/vec_ZZ.h:5, from /usr/include/NTL/ZZX.h:5, from /usr/include/NTL/ZZXFactoring.h:5, from NTLconvert.h:22, from facNTLzzpEXGCD.h:92, from algext.cc:29: /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options. Shouldn't we solve this problem by removing this outdated singular version? Is there anything that depends on it? (In reply to Thomas Kahle from comment #4) > Shouldn't we solve this problem by removing this outdated singular version? > Is there anything that depends on it? I assume that sage-7.0 depends on singular-3.1.7_p1: root@cheetahnew:/root(17)# grep -U2 singular- /var/lib/layman/sage-on-gentoo/sci-mathematics/sage/sage-7.0.ebuild age/sage-7.0.ebuild >=sci-mathematics/ratpoints-2.1.3 >=sci-mathematics/rw-0.7 ~sci-libs/libsingular-3.1.7_p1[flint] media-libs/gd[jpeg,png] media-libs/libpng:0= -- ~sci-mathematics/sage-data-polytopes_db-20120220 ~sci-mathematics/sage-data-conway_polynomials-0.4 ~sci-mathematics/singular-3.1.7_p1 >=sci-mathematics/sympow-1.018.1 www-servers/tornado That's an interesting little problem that may be the final straw for that ageing version of singular. Upstream sage will be interested too. The python patch is my failure to update it to EAPI 6. I thought I had checked. I will see what I can do. Thank you Thomas for pointing me to this bug. OK python use-flag fixed. As a temporary fix for both singular and libsingular while I am working my brain to something more palatable, probably in autoconf: * create a file /etc/portage/env/cpp11 with the following content CXXFLAGS="${CXXFLAGS} -std=c++11" Then create a file /etc/portage/package.env/singular with the following content: sci-mathematics/singular cpp11 sci-libs/libsingular cpp11 If it doesn't work let me know. Further question: what does eix dev-libs/ntl report? It appears that the failing files don't use or override CXXFLAGS - setting CXXFLAGS=-std=c++11 has no effect on them. (In reply to Dennis Schridde from comment #9) > It appears that the failing files don't use or override CXXFLAGS - setting > CXXFLAGS=-std=c++11 has no effect on them. Correct I have come to the same conclusion. This happens when ntl is built with threads enabled. It uses c++11 threads. Adding -std=c++11 in singular would work if it wasn't for the files that are re-compiled with a .og extension (presumably for debugging). I should see if that can be turned off. In the mean time the real solution is to depend on ntl[-threads]. Breaks flint as well. I'm with Thomas on this one, this thing is a zombie ebuild... Lets try to put it down. The ebuild currently only exists in the sage-on-gentoo overlay, so does the ntl ebuild were the problem originates. It is a pure overlay issue But yes putting down that ebuild would make me feel better. Upstream sage is moving to singular-4 but progress is slow and requires specialized knowledge. (In reply to Dennis Schridde from comment #9) > It appears that the failing files don't use or override CXXFLAGS - setting > CXXFLAGS=-std=c++11 has no effect on them. I believe it would be solved by configuring with "--without-debug" but I am just depending on ntl[-threads]. I doubt that the lack of respect of CXXFLAGS for debugging is solved in singular-4. Although it may be interesting to try CPPFLAGS. Changes pushed to the sage-on-gentoo overlay: {lib}singular depends on ntl[-threads] the package.use/sage file provided by the overlay now specifies that ntl is to be compiled without threads. If you are using the package.use/sage provided, syncing the overlay and merging ntl again will fix the issue. Someone with bugzilla power should close this. |