Created attachment 506552 [details] build.log [ebuild UD] dev-python/matplotlib-1.4.3 [2.0.2] USE="cairo gtk%* latex qt4 qt5 wxwidgets -doc -examples -excel -fltk% -gtk3 -pyside {-test} -tk (-gtk2%)" PYTHON_TARGETS="python2_7 python3_5 -python3_4 (-python3_6)" Trying to recompile matplotlib-1.4.3 with python_targets_python3_5 fails with a segfault, buildlog in the attachment. Version 2.0.2 does work, however 1.5.3-r2 fails as well (different error, so I'll file a separate bug for that if it isn't reported already).
Created attachment 506554 [details] emerge info
Created attachment 506556 [details] environment
I note the build log shows that the error is while building with python2.7. But I don't expect differences with python3.5 (or 3.6).
Same issue with 1.4.3 on amd64. Overriding default CXXFLAGS to replace -O2 with -O1 fixes the problem for me.
I can confirm that replacing CXXFLAGS -O2 with -O1 fixes the problem for me to. What I did was follow: https://wiki.gentoo.org/wiki/Knowledge_Base:Overriding_environment_variables_per_package Which resultet in: # mkdir /etc/portage/env # echo 'CXXFLAGS="${CXXFLAGS} -O1"' > /etc/portage/env/matplotlib-build-fix # echo "=dev-python/matplotlib-1.4.3 matplotlib-build-fix" > /etc/portage/package.env # emerge matplotlib And it finally went through, the -O2 flag is till there when looking at the messages but the also existing -O1 flag is later in the command and probably wins. Example: x86_64-pc-linux-gnu-g++ -march=native -O2 -pipe -O1 -fno-strict-aliasing -DNDEBUG -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_matplotlib__path_ARRAY_API -DPYCXX_ISO_CPP_LIB=1 -DPYCXX_PYTHON_2TO3=1 -I/usr/lib64/python3.4/site-packages/numpy/core/include -I/usr/lib64/python3.4/site-packages/numpy/core/include -I. -Iextern/agg24/include -Iextern -I/usr/include/python3.4m -c src/_path.cpp -o /var/tmp/portage/dev-python/matplotlib-1.4.3/work/matplotlib-1.4.3-python3_4/build/temp.linux-x86_64-3.4/src/_path.o
I'm also affected by this. Switching to -O1 workaround, as described by Theo, did the trick.
I as well can confirm the same issue, as well as it being fixed by switching CXXFLAGS from -O2 to -O1
*** Bug 639746 has been marked as a duplicate of this bug. ***
I think this is the same as https://bugzilla.redhat.com/show_bug.cgi?id=1506809 and by extension https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82264. What is the proper approach here? Force -O1 in the matplotlib ebuild for gcc:6 or try to backport the patch and add it to the gcc-6.4.0 ebuild? I also got various ICEs when trying to compile clang, but that was not consistent (in contrast to this one which appears everytime).
According to upstream gcc bug, * broken in 6.4.0, 7.2.0 * working in 4.9.4, 5.4.0, 6.3.0, 7.1.0, 7.2.1 (whatever that may be), 8.0
As a workaround: ~dev-python/matplotlib-1.5.3 does not appear to trigger this bug on x86/amd64. I would recommend, as an immediate fix, address the stabilization bug # 636054.
Same problem specified by Andrew Ammerlaan, I have solved with 1.5.3-r2 unmasking. This version compiles fine without troubles in the same environment
*** Bug 642322 has been marked as a duplicate of this bug. ***
1.5.3-r2 got removed in the meanwhile and stable 1.4.3 still cannot be build with stable gcc. How to proceed on this matter?
In my case I am using 2.1.0-r1 without issues for a long time
Fixed up(In reply to Benedikt Reinartz from comment #9) > I think this is the same as > https://bugzilla.redhat.com/show_bug.cgi?id=1506809 and by extension > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82264. > > What is the proper approach here? Force -O1 in the matplotlib ebuild for > gcc:6 or try to backport the patch and add it to the gcc-6.4.0 ebuild? I > also got various ICEs when trying to compile clang, but that was not > consistent (in contrast to this one which appears everytime). Fixed with https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=253190 which was after 7.2.0 but before 7.3.0. Builds fine using gcc-7.3.0 with USE="-cairo -doc -examples -excel -fltk -gtk -gtk3 -latex -pyside -qt4 -qt5 {-test} -tk -wxwidgets" PYTHON_TARGETS="python2_7 python3_5" CFLAGS="-march=skylake -pipe -O2" CXXFLAGS="-march=skylake -pipe -O2" but maybe someone else can confirm. Not sure whether to submit a backported patch or should ~gcc-7.2.0 get dropped?
Cleanup done in fe830575e425a875093a98fc75702338dba6b35a.
(In reply to Peter Levine from comment #16) > > Fixed with https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=253190 > which was after 7.2.0 but before 7.3.0. Builds fine using gcc-7.3.0 with > USE="-cairo -doc -examples -excel -fltk -gtk -gtk3 -latex -pyside -qt4 -qt5 > {-test} -tk -wxwidgets" PYTHON_TARGETS="python2_7 python3_5" > CFLAGS="-march=skylake -pipe -O2" CXXFLAGS="-march=skylake -pipe -O2" but > maybe someone else can confirm. > > Not sure whether to submit a backported patch or should ~gcc-7.2.0 get > dropped? It will get dropped IMHO.