When emerging dev-python/matplotlib-1.5 build fails with error: ERROR: dev-python/matplotlib-1.5.0::gentoo failed (compile phase): (no error message) Call stack: ebuild.sh, line 133: Called src_compile environment, line 4117: Called distutils-r1_src_compile environment, line 1181: Called _distutils-r1_run_foreach_impl 'python_compile' environment, line 438: Called python_foreach_impl 'distutils-r1_run_phase' 'python_compile' environment, line 3574: Called multibuild_foreach_variant '_python_multibuild_wrapper' 'distutils-r1_run_phase' 'python_compile' environment, line 2606: Called _multibuild_run '_python_multibuild_wrapper' 'distutils-r1_run_phase' 'python_compile' environment, line 2604: Called _python_multibuild_wrapper 'distutils-r1_run_phase' 'python_compile' environment, line 773: Called distutils-r1_run_phase 'python_compile' environment, line 1174: Called python_compile environment, line 3101: Called wrap_setup 'distutils-r1_python_compile' environment, line 4888: Called distutils-r1_python_compile 'build' '--build-lib=/var/tmp/portage/dev-python/matplotlib-1.5.0/work/matplotlib-1.5.0-python3_5/build/build/lib' environment, line 1046: Called esetup.py 'build' 'build' '--build-lib=/var/tmp/portage/dev-python/matplotlib-1.5.0/work/matplotlib-1.5.0-python3_5/build/build/lib' environment, line 1669: Called die The specific snippet of code: "${@}" || die "${die_args[@]}" || return ${?} with the following use options: [ebuild R ] dev-python/matplotlib-1.5.0::gentoo USE="cairo examples excel gtk3 latex wxwidgets -doc -fltk -gtk2 -pyside -qt4 -qt5 {-test} -tk" P YTHON_TARGETS="python2_7 python3_5 -python3_3 -python3_4" 0 KiB Reproducible: Always
Created attachment 418904 [details] emerge --info
Created attachment 418906 [details] build.log
same here
Do you have pycairo or dev-python/cairocffi installed? And if yes, which version?
Which versions of dev-python/pygobject are installed?
(In reply to Justin Lecher from comment #5) > Which versions of dev-python/pygobject are installed? Just had the same problem here, apparently due to the update to dev-lang/python-3.5.0-r3. "emerge -1 dev-python/pygobject:3" fixed it, recompiling version 3.18.2. I don't think it is catched by emerge @preserved-rebuild. Best regards, Bernd
In response to Justin's question about installed pycairo and cairo: % sudo qlist -I cairo dev-cpp/cairomm dev-python/pycairo x11-libs/cairo % sudo emerge x11-libs/cairo dev-python/pycairo -pv [ebuild U ] x11-libs/cairo-1.14.6::gentoo [1.14.4::gentoo] USE="X glib opengl svg xcb (-aqua) -debug (-directfb) (-gles2) -static-libs -valgrind -xlib-xcb" ABI_X86="(64) -32 (-x32)" 35,196 KiB [ebuild R ] dev-python/pycairo-1.10.0-r5::gentoo USE="svg xcb -doc -examples {-test}" PYTHON_TARGETS="python2_7 python3_5 -python3_3 -python3_4" 0 KiB
Same here with =dev-lang/python-3.4.3-r4, =dev-lang/python-exec-2.1, and the latest eselect-python No errors with =dev-lang/python-3.4.3-r2, =dev-lang/python-exec-2.02.
Fixed for me by reemerging pygobject and pycairo along with today's cairo update.
(In reply to Jeff Kowalczyk from comment #9) > Fixed for me by reemerging pygobject and pycairo along with today's cairo > update. Same issue, same solution.
I think problem is in `pymalloc` enabled by default in new ebuilds with SLOT="3.4/3.4m", SLOT="3.5/3.5m" python-updater should somehow detect this problem and reemerge packages. Fixed for me by reemerging pycairo and numpy.
pymalloc has always been enabled by default; the only change we made was to name the resulting python binaries, libraries and headers as upstream wants them. Can anyone exactly explain why rebuilding pygobject resolves this build failure? I would like to better understand it.
Oh, I see. It's probably just the extension module naming convention. /usr/lib64/python3.5/site-packages/gi/_gi_cairo.cpython-35-x86_64-linux-gnu.so /usr/lib64/python3.5/site-packages/gi/_gi.cpython-35-x86_64-linux-gnu.so versus /usr/lib64/python3.5/site-packages/gi/_gi_cairo.cpython-35m-x86_64-linux-gnu.so /usr/lib64/python3.5/site-packages/gi/_gi.cpython-35m-x86_64-linux-gnu.so
*** Bug 567982 has been marked as a duplicate of this bug. ***
I had to unmerge dev-python/cairocffi and media-gfx/cairosvg what depends on it. Only after that matplotlib was able to finish its configure phase.
(In reply to David Kredba from comment #15) > I had to unmerge dev-python/cairocffi and media-gfx/cairosvg what depends on > it. Only after that matplotlib was able to finish its configure phase. By removing the above mentioned packages you haven't solved the problem, because matplotlib will no longer try to build the extension. The solution has been already mentioned in the bug report: re-emerge pygobject.
It builds it because it uses dev-python/pycairo as cairo dependency and not the second option dev-python/cairocffi. In the ebuild there is OR cairo? ( || ( dev-python/pycairo[${PYTHON_USEDEP}] dev-python/cairocffi[${PYTHON_USEDEP}] ) ) In my case rebuilding before mentioned packages was not helping but removing the second python-cairo "bridge" helped. dev-python/matplotlib-1.5.0::gentoo was built with the following: USE="cairo excel fltk gtk3 latex qt5 tk wxwidgets -doc -examples -gtk2 -pyside -qt4 -test" ABI_X86="64" PYTHON_TARGETS="python2_7 python3_5 -python3_3 -python3_ 4" CFLAGS="-O2 -ggdb -pipe -march=core2 -frecord-gcc-switches -fno-strict-aliasing" CXXFLAGS="-O2 -ggdb -pipe -march=core2 -frecord-gcc-switches -fno-strict-liasin g"
This may be off-topic, but matplotlib seems to deprecate pycairo, by emitting this run-time message: ------------------------------------------------------------------------ /usr/lib64/python3.4/site-packages/matplotlib/backends/backend_gtk3agg.py:18: UserWarning: The Gtk3Agg backend is known to not work on Python 3.x with pycairo. Try installing cairocffi. "The Gtk3Agg backend is known to not work on Python 3.x with pycairo. " ------------------------------------------------------------------------ This applies (at least) to 1.4.2 <= matplotlib <= 1.5.1. See <src tree top>/lib/matplotlib/backends/backend_gtk3agg.py I think einfo will be nice if the user don't have dev-python/cairocffi. (Or drop pycairo altogether?) # BTW I'd prefer that kind of einfo _before_ building, if emerge -a or -p is executed.
A matter of re-emerging, so nothing to do for us.
