This qtwebengine GN patch already assigns AR correctly one line above
to '--ar \"$$which(ar)\"' , drop the newly added upstream AR assignment
as it triggers build failure:
"
[184/187] CXX tools/gn/target.o
[185/187] CXX tools/gn/visual_studio_writer.o
[186/187] AR gn_lib.a
[187/187] LINK gn
FAILED: gn
/build/tmp/hosttools/g++ -O3 -fdata-sections -ffunction-sections -Wl,--gc-sections -Wl,-strip-all -Wl,--as-needed -static-libstdc++ -pthread -o gn -Wl,--start-group tools/gn/gn_main.o base.a gn_lib.a -Wl,--end-group -ldl
/build/tmp/hosttools/ld: base.a: error adding symbols: archive has no index; run ranlib to add one
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
Project ERROR: GN build error!
make[2]: *** [Makefile:98: sub-gn-pro-make_first] Error 3
"
MJ: for GN(-native) build we don't want to respect QMAKE_AR, we want ar for
host architecture and use $$which(ar) (will will be similar to $$first(BUILD_AR)
with BUILD_AR from bitbake.conf)
MJ: Refresh other patches to apply on top of this change.
MJ: it's not reproducible with qemux86-64 (which I was using to test the last upgrade):
martin@jama /OE/build/oe-core/tmp-glibc/work $ ls -lah core2-64-oe-linux/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a cortexa15t2hf-neon-oe-linux-gnueabi/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a
-rw-r--r-- 1 martin martin 99K Aug 8 22:01 core2-64-oe-linux/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a
-rw-r--r-- 1 martin martin 3.3K Aug 8 21:10 cortexa15t2hf-neon-oe-linux-gnueabi/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a
martin@jama /OE/build/oe-core/tmp-glibc/work $ file core2-64-oe-linux/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a cortexa15t2hf-neon-oe-linux-gnueabi/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a
core2-64-oe-linux/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a: thin archive with 1168 symbol entries
cortexa15t2hf-neon-oe-linux-gnueabi/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release/base.a: thin archive with 1650553701 symbol entries
The issue is that gn build will use arm-oe-linux-gnueabi-gcc-ar from QMAKE_AR which is correct for
target libraries, but in this case it's used for native gn and arm-oe-linux-gnueabi-gcc-ar doesn't
support native x86_64 host (while x86_64-oe-linux-gcc-ar used in qemux86-64 builds was fine, because
the architecture is compatible):
qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/build/src/3rdparty/gn/out/Release $ ninja -v gn 2>&1
[1/2] rm -f base.a && /OE/build/oe-core/tmp-glibc/work/cortexa15t2hf-neon-oe-linux-gnueabi/qtwebengine/5.15.10+gitAUTOINC+c7e716ef1f_ecc2bb74f1-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc-ar rcsT base.a base/callback_internal.o base/command_line.o base/environment.o base/files/file.o base/files/file_enumerator.o base/files/file_path.o base/files/file_path_constants.o base/files/file_util.o base/files/scoped_file.o base/files/scoped_temp_dir.o base/json/json_parser.o base/json/json_reader.o base/json/json_writer.o base/json/string_escape.o base/logging.o base/md5.o base/memory/ref_counted.o base/memory/weak_ptr.o base/sha1.o base/strings/string_number_conversions.o base/strings/string_piece.o base/strings/string_split.o base/strings/string_util.o base/strings/string_util_constants.o base/strings/stringprintf.o base/strings/utf_string_conversion_utils.o base/strings/utf_string_conversions.o base/third_party/icu/icu_utf.o base/timer/elapsed_timer.o base/value_iterators.o base/values.o base/files/file_enumerator_posix.o base/files/file_posix.o base/files/file_util_posix.o base/posix/file_descriptor_shuffle.o base/posix/safe_strerror.o base/strings/string16.o
[2/2] /OE/build/oe-core/tmp-glibc/hosttools/g++ -O3 -fdata-sections -ffunction-sections -Wl,--gc-sections -Wl,-strip-all -Wl,--as-needed -static-libstdc++ -pthread -o gn -Wl,--start-group tools/gn/gn_main.o base.a gn_lib.a -Wl,--end-group -ldl
FAILED: gn
/OE/build/oe-core/tmp-glibc/hosttools/g++ -O3 -fdata-sections -ffunction-sections -Wl,--gc-sections -Wl,-strip-all -Wl,--as-needed -static-libstdc++ -pthread -o gn -Wl,--start-group tools/gn/gn_main.o base.a gn_lib.a -Wl,--end-group -ldl
/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: base.a: error adding symbols: archive has no index; run ranlib to add one
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
$ arm-oe-linux-gnueabi-gcc-ar --help | grep supported.targets
recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/../../libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/12.1.0/ar:
supported targets: elf32-littlearm elf32-littlearm-fdpic elf32-bigarm elf32-bigarm-fdpic elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex plugin
$ ar --help | grep supported.targets
ar:
supported targets: elf64-x86-64 elf32-i386 elf32-iamcu elf32-x86-64 pei-i386 pe-x86-64 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex plugin
It would be better to force gn build to respect
BUILD_AR = "${BUILD_PREFIX}ar"
instead of "$$which(ar)" here or better just using separate gn-native recipe like meta-browser does since:
c5ff301787
but meta-qt5 is dead-end and I don't care enough to fix this.
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Qt5 OpenEmbedded/Yocto Project layer
This layer depends on:
URI: https://github.com/openembedded/openembedded-core (branch: master)
When building stuff like qtdeclarative, qtquick, qtwebkit, make
sure that you have required PACKAGECONFIG options enabled in qtbase
build, see qtbase recipe for detail.
Some recipes like qtwebengine would need 32bit multilib compiler on build
host, especially when target to be built is 32bit, e.g. arm since it builds
v8 engine which requires $CC -m32 to work, so ensure that host compiler
can generate 32bit code, on archlinux distributions this would be
pacman -S lib32-gcc-libs lib32-glibc
Contributing
Please submit any patches against the meta-qt5 layer by using the
GitHub pull-request feature. Fork the repo, make a branch, do the
work, rebase from upstream, create the pull request, yada-yada.
Maintainers
- Martin 'JaMa' Jansa martin.jansa@gmail.com
- Otavio Salvador otavio@ossystems.com.br
Yocto Project Compatible
meta-qt5 has Yocto Project Compatible status since 2013. Check it at: https://www.yoctoproject.org/product/meta-qt5
