Chromium browser build failure

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:

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.

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.

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?

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.

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.

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:

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).

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 (32.04 KiB) Viewed 6443 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.

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.

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.

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.

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:

("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):

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 ...

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.

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.