g++ compile of webkit-gtk-2.6.4_build/DerivedSources/JavaScriptCore/inspector/InspectorJSProtocolTypes.cpp Fails with: webkit-gtk-2.6.4/temp/ccTzy2sH.s: Assembler messages: webkit-gtk-2.6.4/temp/ccTzy2sH.s:308: Error: selected processor does not support ARM mode `movw r2,#:lower16:.Lllint_op_enter-.LrelativePCBase' And so on, with various different mov instructions of the same general (16-bit?) form. Reproducible: Always Steps to Reproduce: 1.This was on a distcc build; webkit-gtk typically requires distcc 2.emerge =net-libs/webkit-gtk-2.6.4 3.look at build.log Related to bug 523400, but that was on armv5, seems to be another instance of bugs.webkit.org/show_bug.cgi?id=125581 (webkit devs only test on armv7). It would be nice if there was an option "do-not-use-any-assembler" ;-) Because I use distcc I use "-march=armv6zk -mfpu=vfp -mfloat-abi=hard", which is set in CXX and CXXFLAGS (see the attached make.conf). These flags should be preserved by flag-o-matic.eclass. Despite including them in both places webkit-gtk manages to remove them; see the attached ebuild 'environment' file. When I discovered this I forced them into /usr/lib/distcc/wrapper (which is also attached), however this did not fix the bug. Based on the upstream report I think the tests in the webkit-gtk assembler code are simply wrong. My crossbuild compiler *is* an armv6j one, and I have managed to build =net-libs/webkit-gtk-2.4.4 successfully in the past, so this bug is just 'normal' (I simply can't upgrade from 2.4.4 to 2.4.6). I don't know if the flag stripping is new to 2.6.4 though.
Created attachment 392986 [details] ebuild environment file
Created attachment 392988 [details] emerge --info '=net-libs/webkit-gtk-2.6.4::gentoo'
Created attachment 392990 [details] /etc/portage/make.conf This sets all the architecture specific flags in both the compiler name and CXXFLAGS; necessary because different packages only support the flags in different places. webkit-gtk however manages to remove the flags from both locations.
Created attachment 392992 [details] /usr/lib/distcc/wrapper CXX="g++" results in /usr/lib/distcc/bin/g++ being run and that file is a hard link to the attached 'wrapper', this then runs armv6j-hardfloat-linux-gnueabi-g++-4.8.4 which is a *soft* link to /usr/bin/distcc, which distributes the compilation. The result is that the correct (armv6j) remote compiler is used and, to be safe, it has all the architecture specific flags. Notice the /usr/bin/distcc only distributes the compilation; the pre-processor phase, which should be removing the bogus code but doesn't, happens on the local machine. All the same the pre-processor gets invoked through the wrapper so we know it gets the correct machine flags.
Created attachment 392994 [details] /home/tmp/portage/net-libs/webkit-gtk-2.6.4/temp/build.log Complete build log (xz compressed.)
pelicone temp # emerge -pqv '=net-libs/webkit-gtk-2.6.4::gentoo' [ebuild NS ] net-libs/webkit-gtk-2.6.4 [2.4.7] USE="egl geoloc gstreamer introspection jit libsecret opengl spell webgl -coverage -debug -doc {-test}"
Please report this to upstream -> bugs.webkit.org This is "normal", I mean, upstream only works with arm7 and, then, every version they release is prone to stop working with older arms... but they are still interested in getting bug reports for noticing this problems Thanks
I suggest simply masking 2.6.4 on arm; 2.4.7 does build. armv7 systems can run KDE without any problem, the point of using Gnome is to get something a little lighter weight that can perform ok on smaller systems. Unfortunately both epiphany and midori depend on webkit-gtk, so while, as Darwin pointed out, evolution is a waste of time it's difficult to break the dependency on webkit-gtk in a gnome system with a GUI.
