| Summary: | =www-client/chromium-32.0.1700.14 bails out with "Unrecognized HOST_OS: Linux" during configuration of bundled ffmpeg | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Vasco Gervasi <yellowhat46> |
| Component: | Current packages | Assignee: | Chromium Project <chromium> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
example fix
ffmpeg_arm_config.patch ffmpeg_arm_config.patch |
||
|
Description
Vasco Gervasi
2013-11-17 08:25:18 UTC
chromium/scripts/build_ffmpeg.sh:
------------
case $(uname -sm) in
Linux\ i386)
HOST_OS=linux
HOST_ARCH=ia32
JOBS=$(grep processor /proc/cpuinfo | wc -l)
;;
Linux\ x86_64)
HOST_OS=linux
HOST_ARCH=x64
JOBS=$(grep processor /proc/cpuinfo | wc -l)
;;
Darwin\ i386)
HOST_OS=mac
HOST_ARCH=ia32
JOBS=$(sysctl -n hw.ncpu)
;;
Darwin\ x86_64)
HOST_OS=mac
HOST_ARCH=x64
JOBS=$(sysctl -n hw.ncpu)
;;
MINGW*)
HOST_OS=win
HOST_ARCH=ia32
JOBS=$NUMBER_OF_PROCESSORS
;;
*)
echo "Unrecognized HOST_OS: $(uname)"
echo "Patches welcome!"
exit 1
;;
esac
-----------------------------------
need fix
Created attachment 363394 [details, diff]
example fix
Thanks that worked for me + 17 Nov 2013; Mike Gilbert <floppym@gentoo.org> + +files/chromium-build_ffmpeg-r0.patch, chromium-32.0.1700.14.ebuild, + chromium-33.0.1707.0.ebuild: + Fix detection of x86 HOST_OS when configuring ffmpeg, bug 491466. Thanks to + megabaks for the the solution. Leaving this bug open until it makes it upstream. phajdan.jr: If that's something you can easily take care of, please do. If you would prefer that I submit it myself, that's fine too. Have same issue on ARM with www-client/chromium-32.0.1700.14 (www-client/chromium-32.0.1700.6 compiled fine). Is the any way to extend this patch for ARM too? Hmm... the HOST_ARCH variable doesn't seem to be used in the script at all. We could probably remove that detection altogether, which would resolve the problem on ARM. Created attachment 363498 [details, diff]
ffmpeg_arm_config.patch
Here is the basic patch to make ffmpeg part configured proper on ARM.
1) Added "neon" cpu feature detection. I think, this part should be changed in order to use www-client/chromium package "neon" USE flag. Also, please note, for ARM we need override TARGET_ARCH (TARGET_ARCH is "arm" all the time, don't matter have use "neon" cpu feature or package USE flag. Probably, some chromium issue?).
2) All cross-compilation staff will be used only if host is not ARM.
3) I also think, that all "add_flag_common" lines with "--extra-cflags=" should be moved to cross-compilation stuff (under if-fi). We have all we need in make.conf file already.
I am testing this patch now with user-patch feature. All ffmpeg related code compiled just fine, but I need about 12 more hours to compiled chromium on my ARM box to be 100% sure.
I would be appreciated if some one could help me with patch corrections and testing, to make new chromium versions work on ARM in proper way. :-)
You definitely do not want to set TARGET_ARCH based on uname or /proc/cpunifo. That gets passed in from the ebuild via the second command line parameter ($2). Mike, sure, TARGET_ARCH should be passed via the second command line parameter ($2), but looks like now we have "arm" passed as second command line parameter all the time (with or without "neon" USE flag). I have tested this on my ARM box. Created attachment 363536 [details, diff]
ffmpeg_arm_config.patch
Looks like we need minor ebuild correction, for chromium-32.0.1700.14.ebuild it's 403 line:
chromium/scripts/build_ffmpeg.sh linux ${target_arch} "${PWD}" config-only || die
should be improved for ARM, so, we will have proper "arm-neon" TARGET_ARCH instead of "arm" in case of "neon" USE flag.
I have successfully emerged www-client/chromium-32.0.1700.14 on my ARM box with ffmpeg patch, with "neon" USE flag and "arm-neon" passed to build_ffmpeg.sh script via second command line parameter. That's looking pretty good, thanks. Ok, added that to the patch. This seems to be fixed. Thank you for the patches. |
