Chromium browser build failure


47 posts   Page 1 of 2   1, 2
by mpthompson » Tue Jun 05, 2012 6:26 am
I know that several people have been eager to get a running version of the Chromium browser on Raspbian. Unfortunately, we've been having a devil of a time getting it to build. Plugwash tells me this is not unexpected as even the Debian build team is having a hard time getting the latest versions to build under Debian.

After 23+ hours, my latest build attempt for the chromium browser failed. The information related to the failure is documented in our bug base here:

https://bugs.launchpad.net/raspbian/+bug/1008327

In a few hours the log files will be synced and the full log can be read here (a shorter log file from a previous build attempt is there at the moment):

http://archive.raspbian.org/raspbian/lo ... rowser.log

Looking at the error, my guess is that the API to the MediaStreamDependencyFactory class has changed. I would assume this object is provided by a dependency of chromium that has since been updated and no longer supports the specific API that chromium is using. Thus the build failure.

It would be terrific if someone could look into this further and suggest a fix. If the suggestion makes sense, I'll make the changes in the package and give the build another try. If the fix works, you would be a hero to many Raspbian users.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by bbb » Wed Jun 06, 2012 8:24 am
been looking at this issue .. someone else pointed out on IRC this set of changes that looks to stopped ARM builds working: http://groups.google.com/a/chromium.org ... 19b5&pli=1

Managed with apt-get source, apt-get build-dep; dpkg-buildpackage to reproduce the build error, which I have fixed. But, now I get a another build error, so its going to take a bit of time to work through all the issues and get a patch file together.
Posts: 51
Joined: Sat Jun 02, 2012 9:52 am
by bbb » Wed Jun 06, 2012 7:02 pm
phew, almost there :) fixed up the interface mismatches for media_stream_impl and media_stream_dependency_factory.

Getting these linker errors now, not sure how to fix them need to do a bit of research / googling:
Code: Select all
  LINK(target) out/Release/chrome
out/Release/obj.target/skia/../skia_opts/third_party/skia/src/opts/opts_check_arm.o: In function `SkMemset16GetPlatformProc()':
/root/chromium-browser-18.0.1025.151~r130497/src/third_party/skia/src/opts/opts_check_arm.cpp:36: undefined reference to `arm_memset16'
out/Release/obj.target/skia/../skia_opts/third_party/skia/src/opts/opts_check_arm.o: In function `SkMemset32GetPlatformProc()':
/root/chromium-browser-18.0.1025.151~r130497/src/third_party/skia/src/opts/opts_check_arm.cpp:46: undefined reference to `arm_memset32'
collect2: ld returned 1 exit status
make[1]: *** [out/Release/chrome] Error 1
make[1]: Leaving directory `/root/chromium-browser-18.0.1025.151~r130497/src'
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
Posts: 51
Joined: Sat Jun 02, 2012 9:52 am
by ScoobyDoo » Wed Jun 06, 2012 8:53 pm
Good work :) hopefully a successful build won't be too far away
User avatar
Posts: 71
Joined: Wed Apr 04, 2012 2:52 pm
Location: Staffordshire, UK
by mpthompson » Thu Jun 07, 2012 12:01 am
Terrific work on tracking the issues down. It will be great to get a working chromium browser on Raspbian.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by bbb » Thu Jun 07, 2012 9:31 am
Well ... good and bad news.

The good news I managed to hack the build system to work around the undefined reference(s) problem and got a whole lot of shiny .deb files out :)

The bad news is the build does not work after installation, it does not display ANY pages - not even the settings page.

I will get the changes I made patched up - might be be an issue with build system I am using from here viewtopic.php?f=66&t=7345 and might work better if built on 'real' hardware ...

Also now I understand Chromium's build system a bit better, I need to check how older versions of are built like in Debian 'squeeze'.

There is a lot references to ARMv7 in some of the build system files, and not a lot for ARMv6 - almost like support has been dropped to focus on v7 upstream by Chromium :(
Posts: 51
Joined: Sat Jun 02, 2012 9:52 am
by FA-MAS » Thu Jun 07, 2012 7:35 pm
Noob here, but I thought that's why Raspian exists, because debian-armhf in Wheezy doesn't support ARMv6 and why mpthompson setup a system to recompile all these packages with the support. Just speaking out my a** here, but you're trying to fix using mpthompson's sources which have been been filtered to remove the ARMv7 stuff?
Posts: 14
Joined: Wed May 30, 2012 10:51 pm
by Baranyk » Thu Jun 07, 2012 7:44 pm
The reason this is such a hard issue is because the automated attempt to build Chromium for armv6 failed, so the team didn't even have a chance to check for armv7 contamination.

Sometimes packages will even build for armv6 with the automated code, but only to find out they have armv7 code in them once they're installed and fail to run.

In either case, the Raspbian team has to go back to the source, and figure out where the issues are in the build. This can be extremely hard manual work. Doubly so when the build succeeds but is armv7 dirty.

Short story of it is: Chromium failed to build for armv6 using the autobuild tool. Now we have to get it to build. Sounds like that was accomplished, but now the program is bugged. Need to figure out where the bugs are, and if they have armv7 code in them.
Posts: 7
Joined: Sat Jun 02, 2012 6:32 pm
Location: Pennsylvania, USA
by mpthompson » Fri Jun 08, 2012 12:35 am
Below is a link to a helper script that we've been using to determine if code builds armv7 clean or not. It unpacks .deb packages and scans each file using 'readelf -A' to determine if the presence of armv7 code. This technique has seemed to work fairly reliably for the Raspbian project.

A module with armv7 code has output as follows:

$ readelf -A sample_file
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-A"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3-D16
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_VFP_args: VFP registers
Tag_DIV_use: Not allowed

A module with armv6 code looks as follows:

$ readelf -A sample_file
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "6"
Tag_CPU_arch: v6
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_VFP_args: VFP registers
Tag_DIV_use: Not allowed

The output above is using readelf from Debian Wheezy. I've seen output from readelf on earlier Debian Squeeze systems looking different so the script linked below may need to be adjusted on them.

The link to the script is here:

http://pastebin.com/BtSdvrXM

Below is example output from the openjdk-7 deb packages. Some of which are armv7 dirty and others clean.

$ v7clean *.deb
v7_clean icedtea-7-jre-cacao_7~u3-2.1.1~pre1-2_armhf.deb
v7_dirty icedtea-7-jre-jamvm_7~u3-2.1.1~pre1-2_armhf.deb
v7_dirty openjdk-7-dbg_7~u3-2.1.1~pre1-2_armhf.deb
v7_clean openjdk-7-demo_7~u3-2.1.1~pre1-2_armhf.deb
v7_clean openjdk-7-jdk_7~u3-2.1.1~pre1-2_armhf.deb
v7_clean openjdk-7-jre_7~u3-2.1.1~pre1-2_armhf.deb
v7_dirty openjdk-7-jre-headless_7~u3-2.1.1~pre1-2_armhf.deb

If you want to see which specific files in the packages are dirty, there is a echo statement which can be uncommented to list the name of the specific files.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by bbb » Fri Jun 08, 2012 10:01 am
Baranyk wrote:Short story of it is: Chromium failed to build for armv6 using the autobuild tool. Now we have to get it to build. Sounds like that was accomplished, but now the program is bugged. Need to figure out where the bugs are, and if they have armv7 code in them.


Yep that pretty much sums it up. I am not using the autobuild tool, just doing the steps manually :) .. and just to make things more interesting, plugwash has said that chromium is not building upstream for debian 'wheezy' in the armel AND armhf ports.

mpthompson wrote:Below is a link to a helper script that we've been using to determine if code builds armv7 clean or not. It unpacks .deb packages and scans each file using 'readelf -A' to determine if the presence of armv7 code. This technique has seemed to work fairly reliably for the Raspbian project.
....
The link to the script is here:

http://pastebin.com/BtSdvrXM
...

Thanks, I check will tonight when I finish at work and get back home.

Did not do any more work on this last night (Thursday) was messing about with USB hubs and power supplies :)
Posts: 51
Joined: Sat Jun 02, 2012 9:52 am
by plugwash » Fri Jun 08, 2012 1:21 pm
FA-MAS wrote:Noob here, but I thought that's why Raspian exists, because debian-armhf in Wheezy doesn't support ARMv6 and why mpthompson setup a system to recompile all these packages with the support. Just speaking out my a** here, but you're trying to fix using mpthompson's sources which have been been filtered to remove the ARMv7 stuff?

We do not and almost certainly cannot automatically filter source.

We have changed the compiler defaults so that they build armv6+vfp code. For the vast majority of packages having the compiler set up to produce suitable code by default and having all static libaries on the system "clean" is sufficient to make the binaries come out "clean".

However a minority of packages override the compiler defaults for various reasons resulting in the packages coming out contaminated with armv7 code.

We have a tool that tries to detect if a package is contaminated (by reading elf headers) and refuse it entry to the repo. However this tool is NOT perfect and suffers from both false positives (where armv7 code is present but won't be run on a Pi due to runtime detection) and false negatives (mostly these involve JIT compilers).
Forum Moderator
Forum Moderator
Posts: 2395
Joined: Wed Dec 28, 2011 11:45 pm
by bbb » Sat Jun 09, 2012 1:47 pm
I have also got chromium 17.0.963.83~r127885 built for raspbian (it is the last version to build successfully in wheezy armhf).
It has the same problem, will not display any pages as seen in the screenshot below:-
screen.png
screen.png (32.04 KiB) Viewed 6131 times

I've checked the 17 and 18 builds using the v7clean script, and is reported to be clean - so really quite stuck to what is wrong at the moment.
Posts: 51
Joined: Sat Jun 02, 2012 9:52 am
by obarthelemy » Sat Jun 09, 2012 11:21 pm
Just a useless cheer post. Having a good browser on the Pi is important. The work you're doing is highly appreciated and anticipated :)
Posts: 1399
Joined: Tue Aug 09, 2011 10:53 pm
by bbb » Sun Jun 10, 2012 6:37 pm
obarthelemy wrote:Just a useless cheer post. Having a good browser on the Pi is important. The work you're doing is highly appreciated and anticipated :)


Thanks 8-)

Attached is a patch for getting Chromium 18 to build. Still no progess on why the builds don't work correctly.

3 files changed, I wouldn't recommend trying to get upstream to accept the change to src/skia/skia.gyp since it will break ARM with NEON builds ....

If building Chromium 17, just need the change to skia.gyp AND the glib.patch from 18 (a few headers have changed in recent glib ...)
Attachments
hardfp-build-fix.zip
(1.62 KiB) Downloaded 174 times
Posts: 51
Joined: Sat Jun 02, 2012 9:52 am
by ren41 » Fri Jun 22, 2012 8:23 pm
Just sending positive thoughts - I'd like to upgrade to the Wheezy beta but won't be doing it until Chromium runs....

ren
Posts: 99
Joined: Sat May 26, 2012 8:00 pm
by john.mills » Fri Jun 22, 2012 8:57 pm
If Chromium does run in the future it likely will not be very fast. If Midori and Iceweazel are slow and mostly unusable on the Pi then don't expect Chromium will turn that around and provide a great experience.

You can hold out for Chromium, that is your choice. But by doing so you miss a whole lot more than you gain.
Posts: 81
Joined: Mon Apr 09, 2012 5:23 am
by dom » Fri Jun 22, 2012 9:54 pm
On Debian Squeeze Chromium is miles faster than Midori.
On Debian Wheezy, Midori is miles faster than on Squeeze.

I'd certainly choose Midori and Wheezy over Chromium and Squeeze for now.
However I'm looking forward to the day when someone says Chromium now runs on Wheezy.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4064
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by mpthompson » Fri Jun 22, 2012 11:43 pm
dom wrote:However I'm looking forward to the day when someone says Chromium now runs on Wheezy.


I haven't tried it yet, but is there a reason that we couldn't forward port the Squeeze version of Chromium to Wheezy armel/armhf? I realize it's an older version, but it would be better than nothing. I'm wondering if some dependencies for that version are now missing or there are other reasons why such forward port wouldn't work.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by ren41 » Sat Jun 23, 2012 7:35 am
john.mills wrote:If Chromium does run in the future it likely will not be very fast. If Midori and Iceweazel are slow and mostly unusable on the Pi then don't expect Chromium will turn that around and provide a great experience.

You can hold out for Chromium, that is your choice. But by doing so you miss a whole lot more than you gain.


Using a browser for R&D & testing is a large of my working life & I have to have every browser that a reasonable number of people are likely to run. Chrome is very good & chromium works very well on Squeeze, I think, and provides an acceptable experience. Pages with masses of large images (like www.raspberrypi.org's front page!) occasionally trigger a brief flash of the 'this page has stopped working' message but otherwise I've been very pleasantly surprised. It also doesn't impact on my network connection. I assume from what you say that you haven't tried chromium, but I think you would probably also be surprised by the difference.

By contrast, I found Midori unusable, rendering was poor and 9 times out of 10 it killed my network connection. The CPU chart was almost permanently at 100%.

I should edit that actually to say that I haven't even looked at Midori since I got rid of LXDE in favour of xfce, so maybe that would help with the network connection at least.

ren
Posts: 99
Joined: Sat May 26, 2012 8:00 pm
by andyhorn » Sat Jun 23, 2012 10:13 am
Slightly off topic but I feel it is relevant.

Has anyone had a go at porting Opera mini for the Pi?, it runs on most cell/mobile phones that no doubt have ARM architecture.

This is all beyond my capabilities, I am a bit of a noob on the porting or programming front, just a simple Pi user.

Andy.

BTW I like the hat Mike
[
User avatar
Posts: 23
Joined: Mon Dec 26, 2011 9:30 pm
by williamhbell » Sat Jun 23, 2012 1:34 pm
Hi Andy,

There seems to be little hope of getting Opera running on the PI:

"Opera has no current plans to go open source." [ http://www.opera.com/press/faq/ ]
"We have no short term plans to provide an ARM version." [ http://my.opera.com/community/forums/to ... id=1125362 ]

Regards, Will
User avatar
Posts: 262
Joined: Mon Dec 26, 2011 5:13 pm
by andyhorn » Sat Jun 23, 2012 2:05 pm
Thanks Will, I had no idea that Opera was closed source, please excuse my ignorance.

Andy
[
User avatar
Posts: 23
Joined: Mon Dec 26, 2011 9:30 pm
by jui-feng » Fri Jun 29, 2012 10:55 am
I built chromium from the sources that are currently in Debian Sid (20.0.1132.41~r143299-1), using the dev-vm provided by plugwash. I managed to solve most build errors with some dirty hacks from http://www.cnx-software.com/2012/04/19/ ... -pi-armv6/ , a patch from the chromium bug tracker that should have been commited already, a simple change to gyp, and probably some more things. Now I'm not really sure which of these hacks is actually required and which might cause chromium crashes..

ffmpegsumo.so built from the chromium sources was armv7 at first, but the link above explains how to make it v7-clean. Now I have:
$ ./v7clean /home/[....]/chromium/*.deb
v7_clean chromium_20.0.1132.41~r143299-1rpi1_armhf.deb
v7_clean chromium-browser_20.0.1132.41~r143299-1rpi1_all.deb
v7_clean chromium-browser-dbg_20.0.1132.41~r143299-1rpi1_all.deb
v7_clean chromium-browser-inspector_20.0.1132.41~r143299-1rpi1_all.deb
v7_clean chromium-browser-l10n_20.0.1132.41~r143299-1rpi1_all.deb
v7_clean chromium-dbg_20.0.1132.41~r143299-1rpi1_armhf.deb
v7_clean chromium-inspector_20.0.1132.41~r143299-1rpi1_all.deb
v7_clean chromium-l10n_20.0.1132.41~r143299-1rpi1_all.deb


There's no reason to be happy though, because it still doesn't work. Every single tab crashes.

raspbian@raspi:~$ chromium --enable-logging --v=1 --single-process
Xlib: extension "RANDR" missing on display ":1".
[2513:2532:37438984513:ERROR:proxy_service_factory.cc(84)] Cannot use V8 Proxy resolver in single process mode.
[2513:2532:37439826893:ERROR:proxy_service_factory.cc(84)] Cannot use V8 Proxy resolver in single process mode.
Ungültiger Maschinenbefehl
"Ungültiger Maschinenbefehl" translates to "invalid (machine) instruction".

The logs contain this:
[2092:2116:164004675:VERBOSE1:ffmpeg_stubs.cc(592)] dlopen(/usr/lib/chromium/libffmpegsumo.so) failed, dlerror() says:
/usr/lib/chromium/libffmpegsumo.so: undefined symbol: ff_mpeg4_decoder
[2092:2116:164005501:VERBOSE1:ffmpeg_stubs.cc(592)] dlopen(/usr/lib/chromium/libavutil.so.51) failed, dlerror() says:
/usr/lib/chromium/libavutil.so.51: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden

("cant open shared object file: no such file or directory" – and indeed, /usr/lib/chromium/libavutil.so.51 does not exist.)
So something is probably wrong with the ffmpeg build. debuild shows some warnings about unresolvable symbols in libffmpegsumo.so when creating the package, that might be related.

I don't know how to proceed, so I decided to post the changes in this thread, and maybe someone else can figure it out.

I'm attaching the patch file (in bz2 because phpbb3 complains about *.patch extensions) that quilt generated from my changes to the original source. Import them with quilt import. I'm not sure if this really covers 100% of my changes, because I did them without letting quilt know about it, so I had to run diff manually and port the changes over to a new directory. I don't have the patience to re-run debuild to test, it takes longer than 1 day on the VM (on my machine).

On top of that, I changed the debian/rules file to use all the gyp-defines currently in the raspbian repository (armv7=0, armv6=1, arm_v6=1, arm_neon=0, arm_thumb=0, arm_fpu=vfp, arm_float_abi=hard, v8_use_arm_eabi_hardfloat=true – not sure which armv6 define is correct)

To fix gyp, I added one line to /usr/lib/pymodules/python2.7/gyp/input.py in method/function "ProcessListFiltersInDict". Not sure if this breaks things elsewhere, but it allowed me to compile chromium at least. I added the first line within the for loop at the top of the function: (replace [TAB] with a tab character):
for key, value in the_dict.iteritems():
[TAB]if len(key) == 0: continue
Attachments
fix-rpi.patch.tar.bz2
(2.36 KiB) Downloaded 102 times
Posts: 57
Joined: Sun Mar 04, 2012 11:02 am
by bbb » Mon Jul 02, 2012 2:31 pm
jui-feng wrote:I built chromium from the sources that are currently in Debian Sid (20.0.1132.41~r143299-1), using the dev-vm provided by plugwash. I managed to solve most build errors with some dirty hacks from http://www.cnx-software.com/2012/04/19/ ... -pi-armv6/ , a patch from the chromium bug tracker that should have been commited already, a simple change to gyp, and probably some more things. ...


Well done for getting 20.x to at least build ... I been way too busy the last few weeks to look work on this any further. ... I noticed version 20.x popping up upstream in wheezy .. Good to know it at least builds ...

raspbian@raspi:~$ chromium --enable-logging --v=1 --single-process
Xlib: extension "RANDR" missing on display ":1".
[2513:2532:37438984513:ERROR:proxy_service_factory.cc(84)] Cannot use V8 Proxy resolver in single process mode.
[2513:2532:37439826893:ERROR:proxy_service_factory.cc(84)] Cannot use V8 Proxy resolver in single process mode.
Ungültiger Maschinenbefehl


The invalid instruction message indicates that some code (most likely tucked away in some assembly routines) has sneaked into the build that is not compatible with the Pi's ARMv6 :(

[2092:2116:164004675:VERBOSE1:ffmpeg_stubs.cc(592)] dlopen(/usr/lib/chromium/libffmpegsumo.so) failed, dlerror() says:
/usr/lib/chromium/libffmpegsumo.so: undefined symbol: ff_mpeg4_decoder
[2092:2116:164005501:VERBOSE1:ffmpeg_stubs.cc(592)] dlopen(/usr/lib/chromium/libavutil.so.51) failed, dlerror() says:
/usr/lib/chromium/libavutil.so.51: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden


This should not be a problem, ffmpeg / avlib is only needed for embedded video and audio playback, normal HTML rendering should work without it loaded.

I have reproduced the chroot environment in the QEMU image on a local install of Linux on my Intel i5 with 4 cores @ 4.6Ghz, SSD and 8G of ram for compiling stuff :-) So should be a bit quicker than running in virtual box with only 2 cores. I have a look tonight at what I had vs. your patches, as I don't remember seeing the invalid instruction crash.
Posts: 51
Joined: Sat Jun 02, 2012 9:52 am
by jui-feng » Mon Jul 02, 2012 4:26 pm
bbb wrote:The invalid instruction message indicates that some code (most likely tucked away in some assembly routines) has sneaked into the build that is not compatible with the Pi's ARMv6 :(

The gyp files I changed add at least one assembler file to the build, providing memset16 and memset32 functions (or similar). I noticed there are quite a few assembler files in the ffmpeg build as well, because ffmpeg apparently used a wrong arm assembler file at first, and when compiling vp8_arm.o (or similar) it produced loads of "invalid instruction ldrhcs" (AFAIR) errors. The solution was to call ./configure in ffmpeg and copy over the resulting config.h file to some special chromium directory (you can probably tell from the patch). Since, as you said, ffmpeg is not used to display the new-tab page, that's probably not the cause of my crash.

I have a look tonight at what I had vs. your patches, as I don't remember seeing the invalid instruction crash.
Don't be surprised if you find some fatal flaws with my patch, it is the result of "call debuild", "come back later to check the error message", "google the error message", "change some files", "try again". And as I said above, it might even be missing some of the changes I made.

BTW, if I am reading the debian buildd status pages correctly, the version of chromium-browser uploaded to unstable two days ago is now building for debian armhf. The last build attempt (of the version that I used for my experiments) "failed", though according to the build log, it failed due to some strange reason. There's no real error message, it was apparently killed while linking the chrome executable due to no activity for 151min. https://buildd.debian.org/status/fetch. ... 1340493739

The new build has started 1d 9h 40m ago, so it should probably be done soon. I'm excited to see if it successfully builds on debian-armhf at least.
Posts: 57
Joined: Sun Mar 04, 2012 11:02 am