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