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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
