The installation fails when i try emerge the package x11-libs/gtk+-2.24.14 with "(Segmentation fault) - core dumped" message. Reproducible: Always Steps to Reproduce: 1. emerge x11-libs/gtk+ 2. 3. Actual Results: The installation fails. Expected Results: emerge the package x11-libs/gtk+ successfully. I try install the package in a Raspberry Pi computer. The x11-libs/gtk+-2.24.12 version has the some problem. libtool: link: armv6j-hardfloat-linux-gnueabi-gcc -shared -fPIC -DPIC .libs/imviqr.o -Wl,-rpath -Wl,/var/tmp/portage/x11-libs/gtk+-2.24.12/work/gtk+-2.24.12/gdk/.libs -Wl,-rpath -Wl,/var/tmp/portage/x11-libs/gtk+-2.24.12/work/gtk+-2.24.12/gtk/.libs -L/var/tmp/portage/x11-libs/gtk+-2.24.12/work/gtk+-2.24.12/gdk/.libs -Wl,--as-needed ../../gdk/.libs/libgdk-x11-2.0.so ../../gtk/.libs/libgtk-x11-2.0.so /var/tmp/portage/x11-libs/gtk+-2.24.12/work/gtk+-2.24.12/gdk/.libs/libgdk-x11-2.0.so -lXrender -lXi -lXrandr -lXcursor -lXext -lpangocairo-1.0 -lX11 -lXcomposite -lXdamage -lXfixes -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0 -lm -O2 -march=armv6j -mfpu=vfp -mfloat-abi=hard -Wl,-O1 -Wl,-soname -Wl,im-viqr.so -o .libs/im-viqr.so libtool: link: ( cd ".libs" && rm -f "im-viqr.la" && ln -s "../im-viqr.la" "im-viqr.la" ) libtool: link: armv6j-hardfloat-linux-gnueabi-gcc -shared -fPIC -DPIC .libs/gtkimcontextxim.o .libs/imxim.o -Wl,-rpath -Wl,/var/tmp/portage/x11-libs/gtk+-2.24.12/work/gtk+-2.24.12/gdk/.libs -Wl,-rpath -Wl,/var/tmp/portage/x11-libs/gtk+-2.24.12/work/gtk+-2.24.12/gtk/.libs -L/var/tmp/portage/x11-libs/gtk+-2.24.12/work/gtk+-2.24.12/gdk/.libs -Wl,--as-needed ../../gdk/.libs/libgdk-x11-2.0.so ../../gtk/.libs/libgtk-x11-2.0.so /var/tmp/portage/x11-libs/gtk+-2.24.12/work/gtk+-2.24.12/gdk/.libs/libgdk-x11-2.0.so -lXrender -lXi -lXrandr -lXcursor -lXext -lpangocairo-1.0 -lX11 -lXcomposite -lXdamage -lXfixes -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0 -lm -O2 -march=armv6j -mfpu=vfp -mfloat-abi=hard -Wl,-O1 -Wl,-soname -Wl,im-xim.so -o .libs/im-xim.so libtool: link: ( cd ".libs" && rm -f "im-xim.la" && ln -s "../im-xim.la" "im-xim.la" ) ../../gtk/gtk-query-immodules-2.0 im-am-et.la im-cedilla.la im-cyrillic-translit.la im-inuktitut.la im-ipa.la im-multipress.la im-thai.la im-ti-er.la im-ti-et.la im-viqr.la im-xim.la > gtk.immodules qemu: Unsupported syscall: 229 qemu: uncaught target signal 11 (Segmentation fault) - core dumped /bin/sh: line 1: 29322 Segmentation fault ../../gtk/gtk-query-immodules-2.0 im-am-et.la im-cedilla.la im-cyrillic-translit.la im-inuktitut.la im-ipa.la im-multipress.la im-thai.la im-ti-er.la im-ti-et.la im-viqr.la im-xim.la > gtk.immodules make[3]: *** [gtk.immodules] Error 139 make[3]: Leaving directory `/var/tmp/portage/x11-libs/gtk+-2.24.12/work/gtk+-2.24.12/modules/input' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/x11-libs/gtk+-2.24.12/work/gtk+-2.24.12/modules' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/x11-libs/gtk+-2.24.12/work/gtk+-2.24.12' make: *** [all] Error 2 * ERROR: x11-libs/gtk+-2.24.12 failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=x11-libs/gtk+-2.24.12'`, * the complete build log and the output of `emerge -pqv '=x11-libs/gtk+-2.24.12'`. * The complete build log is located at '/var/tmp/portage/x11-libs/gtk+-2.24.12/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/x11-libs/gtk+-2.24.12/temp/environment'. * Working directory: '/var/tmp/portage/x11-libs/gtk+-2.24.12/work/gtk+-2.24.12' * S: '/var/tmp/portage/x11-libs/gtk+-2.24.12/work/gtk+-2.24.12'
Created attachment 335868 [details] emerge --info report emerge --info report
Created attachment 335870 [details] Build log Build log
We've had quite a few bug report with gtk-query-immodules crashing in the past. It looks like it is one of the most sensitive code in gtk:2 and is prone to fail with bad cflags or, for your case apparently, variations of not widely used hardware. I see nothing wrong with your cflags so here is what you can do: * downgrade your cflags to -O1 and see if it changes anything * install gcc-4.7 and try to build with it, I know it's masked but it is actually quite usable and worth unmasking for testing * see if another distribution shipping images for raspberry has patches for gtk:2 in which case we would most likely want to apply that Ok I now that I wrote that, I just saw the following line in your logs: > qemu: Unsupported syscall: 229 this is most likely the culprit. qemu does not emulate some specific instruction set that your are trying to use via your cflags and since gtk+ needs to call this utility while building it fails. I suggest you install a default gentoo on your raspberry if such image exists or even bootstrap it with another distro and use crossdev + distcc to setup an arm toolchain on a faster computer. That way you should be able to get fast builds without the hassle of failing builds due to qemu limitations. Of course I'm no expert here so if you have any question I suggest you try to find help in #gentoo-arm for example.
Hi Gilles, Thanks for your suggestions. You are right, the gtk+ emerge fine when compiled directly on the raspberry pi (take about 3 hours). (In reply to comment #3) > We've had quite a few bug report with gtk-query-immodules crashing in the > past. It looks like it is one of the most sensitive code in gtk:2 and is > prone to fail with bad cflags or, for your case apparently, variations of > not widely used hardware. > > I see nothing wrong with your cflags so here is what you can do: > * downgrade your cflags to -O1 and see if it changes anything > * install gcc-4.7 and try to build with it, I know it's masked but it is > actually quite usable and worth unmasking for testing > * see if another distribution shipping images for raspberry has patches for > gtk:2 in which case we would most likely want to apply that > > Ok I now that I wrote that, I just saw the following line in your logs: > > > qemu: Unsupported syscall: 229 > > this is most likely the culprit. qemu does not emulate some specific > instruction set that your are trying to use via your cflags and since gtk+ > needs to call this utility while building it fails. > > I suggest you install a default gentoo on your raspberry if such image > exists or even bootstrap it with another distro and use crossdev + distcc to > setup an arm toolchain on a faster computer. That way you should be able to > get fast builds without the hassle of failing builds due to qemu limitations. > > Of course I'm no expert here so if you have any question I suggest you try > to find help in #gentoo-arm for example.