Summary: | www-client/chromium-65.0.3325.146 fails to build on arm64 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Roy Bamford <neddyseagoon> |
Component: | Current packages | Assignee: | Chromium Project <chromium> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arm64, info |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | ARM64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
MAKEOPTS='j1' Build Log for chromium-64.0.3282.186
Patch to fix configuration of ffmpeg on ARM and MIPS |
Description
Roy Bamford
![]() Created attachment 523718 [details]
MAKEOPTS='j1' Build Log for chromium-64.0.3282.186
Makes it easy to see the first error.
With higher MAKEOPTS, more missing files are reported.
Unless someone running ARM64 wants to fix this, I will just drop the keyword. By butchering the ebuild, so it tries to build with gcc-7.3.0-r1 by commenting the clang forcing # if ! tc-is-clang; then # Force clang since gcc is pretty broken at the moment. # CC=${CHOST}-clang # CXX=${CHOST}-clang++ strip-unsupported-flags # fi The missing headers are found. It appears that there needs to be an include of /usr/lib/gcc/aarch64-unknown-linux-gnu/7.3.0/include/g++-v7/ or the clang equivalent, if it has its own include. As per the warning about gcc "being pretty broken at the moment" the build failed later. sys-devel/clang-6.0.0-r1 is installed. The problem when building with clang is that chromium adds "--target=aarch64-linux-gnu" to CFLAGS when the arch is arm64 and the compiler is clang (this comes from build/config/compiler/BUILD.gn). When specifying "--target=aarch64-linux-gnu", clang looks for the headers in /usr/lib/gcc/aarch64-linux-gnu/7.3.0/include/g++-v7/, where they do not exist. If "--target=aarch64-unknown-linux-gnu" is used instead, or the "--target" option is dropped altogether, then the compilation works. The patch below builds here. The ldflags looks wrong but I did not try building with fixing cflags alone. less /etc/portage/patches/www-client/chromium/chromium-build-on-arm64.patch --- ./build/config/compiler/BUILD.gn 2018-04-23 12:55:44.867374501 +0100 +++ ./build/config/compiler/BUILD.gn 2018-04-23 13:22:20.619539044 +0100 @@ -645,8 +645,8 @@ } } else if (current_cpu == "arm64") { if (is_clang && !is_android && !is_nacl && !is_fuchsia) { - cflags += [ "--target=aarch64-linux-gnu" ] - ldflags += [ "--target=aarch64-linux-gnu" ] + cflags += [ "--target=aarch64-unknown-linux-gnu" ] + ldflags += [ "--target=aarch64-unknown-linux-gnu" ] } } else if (current_cpu == "mipsel" && !is_nacl) { if (custom_toolchain == "") { Please try removing the cflags and ldflags assignment entirely. First a minor detail. The build testing today has been on www-client/chromium-67.0.3377.1 rather than 65.0.3325.146, which the bug was opened against. Editing the patch to --- ./build/config/compiler/BUILD.gn 2018-04-23 12:55:44.867374501 +0100 +++ ./build/config/compiler/BUILD.gn 2018-04-23 13:22:20.619539044 +0100 @@ -645,8 +645,6 @@ } } else if (current_cpu == "arm64") { if (is_clang && !is_android && !is_nacl && !is_fuchsia) { - cflags += [ "--target=aarch64-linux-gnu" ] - ldflags += [ "--target=aarch64-linux-gnu" ] } } else if (current_cpu == "mipsel" && !is_nacl) { if (custom_toolchain == "") { builds too. That's a tad ugly as it leaves the empty if statement. If you feel it is more aesthetically pleasing, the following patch works as well: --- chromium-66.0.3359.66/build/config/compiler/BUILD.gn.orig 2018-04-23 11:37:55.857336526 +0200 +++ chromium-66.0.3359.66/build/config/compiler/BUILD.gn 2018-04-23 11:38:43.721158311 +0200 @@ -645,8 +645,8 @@ } } else if (current_cpu == "arm64") { if (is_clang && !is_android && !is_nacl && !is_fuchsia) { - cflags += [ "--target=aarch64-linux-gnu" ] - ldflags += [ "--target=aarch64-linux-gnu" ] + # cflags += [ "--target=aarch64-linux-gnu" ] + # ldflags += [ "--target=aarch64-linux-gnu" ] } } else if (current_cpu == "mipsel" && !is_nacl) { if (custom_toolchain == "") { Tested with chromium-66.0.3359.66 This should be fixed in 67.0.3396.18. I added a patch that disables the compiler_cpu_abi config section. https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/chromium/files/chromium-compiler-r0.patch?id=3800f8726b23842d9dc0c578ac4503dfeae298a8 Hi. I confirm that chromium-67.0.3396.18 builds correctly without user patches. Thanks! Hi. The issue with incorrect target triplet is back again in chromium-67.0.3396.62, at least when not enabling the system-ffmpeg USE flag (which is masked on arm): Chrome configure/build: Running /var/tmp/portage/www-client/chromium-67.0.3396.62/work/chromium-67.0.3396.62/third_party/ffmpeg/configure --disable-everything [...] --enable-cross-compile --cross-prefix=/usr/bin/aarch64-linux-gnu- --target-os=linux --extra-cflags=--target=aarch64-linux-gnu --extra-ldflags=--target=aarch64-linux-gnu [...] --enable-parser=aac,h264 /usr/bin/aarch64-linux-gnu-gcc is unable to create an executable file. C compiler test failed. Created attachment 534420 [details, diff]
Patch to fix configuration of ffmpeg on ARM and MIPS
Attached a patch which fixes configuration of ffmpeg by removing the implicit cross-compilation stuff for ARM and MIPS.
With this ffmpeg builds. The jury is still out on whether chromium as a whole builds for a couple of more hours (currently at [170/14061])... :-)
Unfortunately, it didn't get all the way: [2901/14054] aarch64-unknown-linux-gnu-clang -MMD -MF obj/third_party/ffmpeg/ffmpeg_internal/fft_neon.o.d -DHAVE_AV_CONFIG_H -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -D_ISOC99_SOURCE -D_LARGEFILE_SOURCE -DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DNO_TCMALLOC -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DOPUS_FIXED_POINT -I../../third_party/ffmpeg/chromium/config/Chrome/linux/arm64 -I../../third_party/ffmpeg -I../.. -Igen -I../../third_party/opus/src/include -DHAVE_VFP_ARGS=1 -fno-strict-aliasing -fmerge-all-constants --param=ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -funwind-tables -fPIC -pipe -pthread -fcolor-diagnostics -no-canonical-prefixes -std=gnu11 -c ../../third_party/ffmpeg/libavcodec/aarch64/fft_neon.S -o obj/third_party/ffmpeg/ffmpeg_internal/fft_neon.o FAILED: obj/third_party/ffmpeg/ffmpeg_internal/fft_neon.o <instantiation>:15:9: error: unknown directive .func fft4_neon ^ ../../third_party/ffmpeg/libavcodec/aarch64/fft_neon.S:38:1: note: while in macro instantiation function fft4_neon ^ If compiling fft_neon.S with gcc instead of clang (and removing -fcolor-diagnostics, which gcc does not like), then it works... So, basically, ffmpeg gets built twice. I don't know if this is correct or intentional. The first time it is built with gcc, and the object files end up in third_party/ffmpeg/build.arm64.linux/Chrome/ The second time it is built with clang (using ninja), and the object files end up in out/Release/obj/third_party/ffmpeg/ffmpeg_internal/ I see that the is a patch in files/chromium-ffmpeg-clang.patch to prevent the first build from using clang, but it seems moot if it is rebuilt using clang later anyway? I removed the ffmpeg configure step in chromium-68.0.3438.3. If you encounter errors with that version, please create a new bug report. That works on arm64
>>> Installing (26 of 29) www-client/chromium-68.0.3438.3::gentoo
Hi. chromium-68.0.3438.3 gave me two unrelated build fails, so I created a new issue about that (#657472). Thanks. |