I have ACCEPT_KEYWORD="~amd64" in my /etc/make.conf, and I've emerged glib, gobject-introspection and webkit-gtk several times.

I also tried package.masking webkit-gtk to -r300 and -r201, but I keep getting the same result.

As a last resort, I'm compiling all three packages with CLAGS="-O0 -pipe" to see if maybe it's something to do with optimization issues or instruction set problems.
(I once had telepathy crash randomly with certain SSE options enabled)

OK ... well, 11 is a SIGSEGV (segment violation) signal, which you would expect to have been generated by the kernel in response to a page access. Why this might be I'm not sure, what filesystem is /var/tmp? Does anything show up in dmesg?

The test itself is .. well, who knows, it all depends on whether '--introspect-dump=' accepts a comma delimited set of inputs. Whatever the case two files are being passed to it (intentionally or not).

So, hard to guess really ... the bad page access could be for any number of reasons.

The cause may be with glibc-2.15 ... if you have very aggressive optimization with glibc change your CFLAGS and re-emerge, then try again with webkit. Of course it could simply be that 2.15 is buggy .. it is ~arch after all.

Also, has this machine always been ~arch and/or did you --deep -e when updating to glibc-2.15, in fact what was the process you followed to get 2.15. I'm somewhat conservative in that regard, and besides not using ~arch would under any kind of 'bootstrap' emerge glibc twice (but this probably stems from times yore when doing such things was deemed necessary and not optional, this may nolonger be the case).

lookmiraok wrote:

And thanks a lot. You're helping a TON. I now have an idea why its failing. I couldn't find error code 11 anywhere. (I kept searching for -11

hey np ... hopfully we can figure it out ... as for 11, I think 'man signal' should probably mention it.

I am experiencing the same error, though with earlier versions of webkit-gtk.

I ran into this while doing a revdep-rebuild, which tries to reinstall webkit-gtk-1.6.3-r200. if I try to emerge it tries to upgrade to webkit-gtk-1.6.3-r300 and the same thing happens. I have not tried installing later versions - I assume they are masked by the ~amd64 keyword and I'd rather not unmask them.

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-libs/gobject-introspection:0

(dev-libs/gobject-introspection-1.30.0-r2::gentoo, installed) pulled in by
(no parents that aren't satisfied by other packages in this slot)

(dev-libs/gobject-introspection-1.32.1::gentoo, ebuild scheduled for merge) pulled in by
>=dev-libs/gobject-introspection-1.32 required by (x11-libs/gtk+-3.4.4::gentoo, ebuild scheduled for merge)

net-libs/libsoup:2.4

(net-libs/libsoup-2.38.1::gentoo, ebuild scheduled for merge) pulled in by
>=net-libs/libsoup-2.37.92:2.4[introspection?] required by (net-libs/webkit-gtk-1.8.3-r300::gentoo, ebuild scheduled for merge)

(net-libs/libsoup-2.36.1::gentoo, installed) pulled in by
~net-libs/libsoup-2.36.1 required by (net-libs/libsoup-gnome-2.36.1::gentoo, installed)

x11-libs/pango:0

(x11-libs/pango-1.30.1::gentoo, ebuild scheduled for merge) pulled in by
>=x11-libs/pango-1.30[introspection?] required by (x11-libs/gtk+-3.4.4::gentoo, ebuild scheduled for merge)

(x11-libs/pango-1.29.4::gentoo, installed) pulled in by
(no parents that aren't satisfied by other packages in this slot)

It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously. You may want to try a larger value of
the --backtrack option, such as --backtrack=30, in order to see if
that will solve this conflict automatically.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.

I ran into this error during a revdep-rebuild. I worked around it by manually emerging everything else in the revdep-rebuild list. after doing that I ran rev-deprebuild again and no error occured. I absent mindedly forgot to check whether webkit-gtk was rebuilt or not, so I tried manually emerging it. the emerge of 1.6.3-r300 worked fine.

The problem still seems to be around. I got the SIGSEGV while building pango-1.30.1 during an emerge --update --deep world, and for a while it looked as though my system was fubar. However, in my case, I was able to trace the said introspection error back to some OpenGL library function (by checking the output of dmesg), and in a wild guess I switched from nvidia-drivers to XOrg OpenGL (eselect opengl set n, where n is the item number of the xorg-x11 implementation as shown by eselect opengl list, in my case 2). That did it for me, pango then compiled without any further problems, and after updating the nvidia-drivers, I was able to switch back to nvidia OpenGL (using eselect opengl set n again, this time with the item number of the nvidia drivers).

The problem still seems to be around. I got the SIGSEGV while building pango-1.30.1 during an emerge --update --deep world, and for a while it looked as though my system was fubar. However, in my case, I was able to trace the said introspection error back to some OpenGL library function (by checking the output of dmesg), and in a wild guess I switched from nvidia-drivers to XOrg OpenGL (eselect opengl set n, where n is the item number of the xorg-x11 implementation as shown by eselect opengl list, in my case 2). That did it for me, pango then compiled without any further problems, and after updating the nvidia-drivers, I was able to switch back to nvidia OpenGL (using eselect opengl set n again, this time with the item number of the nvidia drivers).