Bug 534370 – =net-libs/webkit-gtk-2.6.4: armv6 build broken by use of unsupported instructions

• Product: Gentoo Linux
• Status: RESOLVED TEST-REQUEST

[Description John Bowler 2015-01-02 17:54:06 UTC]

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.

[Comment 1 John Bowler 2015-01-02 17:57:03 UTC]

Created attachment 392986 [details]
ebuild environment file

[Comment 2 John Bowler 2015-01-02 17:58:28 UTC]

Created attachment 392988 [details]
emerge --info '=net-libs/webkit-gtk-2.6.4::gentoo'

[Comment 3 John Bowler 2015-01-02 18:00:15 UTC]

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.

[Comment 4 John Bowler 2015-01-02 18:04:46 UTC]

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.

[Comment 5 John Bowler 2015-01-02 18:06:20 UTC]

Created attachment 392994 [details]
/home/tmp/portage/net-libs/webkit-gtk-2.6.4/temp/build.log

Complete build log (xz compressed.)

[Comment 6 John Bowler 2015-01-02 18:07:21 UTC]

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}"

[Comment 7 Pacho Ramos 2015-01-03 10:26:20 UTC]

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

[Comment 8 John Bowler 2015-01-03 17:23:24 UTC]

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.