[Pkg-chromium-maint] Bug#674728: #674728 chromium: FTBFS on armel and armhf

[Florian Will]

Hi,

about the "undefined reference to `vpx_codec_destroy'" and similar vpx*
linker errors on armel and armhf:

The builds have "use_system_vpx=1" defined for gyp. However, upstream
probably dropped support for that flag, or never supported it -- there's
no appearance of that "use_system_vpx" string anywhere in the source
code or debian patches. Also, "remoting/base/decoder_v8.cc" #includes
"third_party/libvpx/libvpx.h", so the source seems to have no support
for system vpx.

So either the source needs to be patched to include system vpx headers,
and the gyp files changed accordingly to use -lvpx when linking. Or the
build system should be convinced to build libvpx.a from the bundled vpx
sources on armel/armhf, just like it does for i386.

I did an armhf test build of chromium-browser from debian sid within a
qemu-user chroot today. Please note that my chroot is not a proper
debian environment, but rather the "raspbian" hard float distribution
for the Raspberry Pi, so your mileage may vary. I did _not_ change any
compile options or gyp defines, so the resulting executable is ARMv7 and
won't work on the raspberry pi (which is ARMv6 only). I did this simply
to test if the build succeeds with the "vpx.patch" quilt patch removed.
And indeed, linking was successful. TBH, I have no experience with gyp
and don't really understand why that patch changes "libvpx" to
"libvpx_include", there might be a good reason for it. All I can tell is
that building without the patch works for me. I have not tried building
_WITH_ the patch yet, so the build failure may also be caused by
something entirely different. It just seemed like a good start.

Maybe this information is useful for someone who actually knows what's
going on with the "libvpx_include" target in remoting.gyp and who could
verify if it is needed, or if it simply breaks the build and that's all.