I dug deeper in this, and there is something odd going on with the patch
functionality. This problem is caused by
recipes-qt/qt5/qtwebengine/0002-chromium-Force-host-toolchain-configuration.patch
not being applied - but only if I add to SRC_URI another patch in a
different layer. What is even weirder is that if I modify this patches'
internal paths instead of adding "patchdir=src/3rdparty/" to the SRC_URI
line, the problem does not occur.
I tracked it down to a problem in patch_do_patch in
meta/classes/patch.bbclass. For this patch, the "if not patchdir in
classes:" check apparently fails. The end result is that quilt push is
called, but not pop, and somehow, this messes up quilt, so this patch
isn't applied. I currently do not know why.
On 2017-11-09 08:22, Daniel Mack wrote:
On Tuesday, October 31, 2017 11:11 AM, Carlos Rafael Giani wrote:
I am having problems building the current WebEngine. Initially, it
builds some tools. It seems that it does so by using the cross compiler,
and not the host one, which could explain the problem I experience:
Once GN is built:
[321/330] CC base/third_party/superfasthash/superfasthash.o
[322/330] CC base/third_party/dynamic_annotations/dynamic_annotations.o
[323/330] AR dynamic_annotations.a
[324/330] CXX tools/gn/command_clean.o
[325/330] CXX tools/gn/loader.o
[326/330] CXX tools/gn/gn_main.o
[327/330] CXX tools/gn/bundle_data_target_generator.o
[328/330] CXX tools/gn/desc_builder.o
[329/330] AR gn_lib.a
[330/330] LINK gn
Building gn manually in a temporary directory for bootstrapping...
Building gn using itself to out/Release...
I get this error:
OSError: [Errno 8] Exec format error
Project ERROR: GN build error!
FWIW, I just ran a build on x86_64 for aarch64 with poky, meta-oe and
meta-qt5 in their 'rocky' branches, and it worked just fine.
Running "file" on build/src/3rdparty/chromium/tools/gn/out/Release/gn
indeed shows that this was built with the wrong compiler:
build/src/3rdparty/chromium/tools/gn/out/Release/gn: ELF 32-bit LSB
executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked
On my machine:
build/src/3rdparty/chromium/tools/gn/out/Release/gn: ELF 64-bit LSB
executable, x86-64, version 1 (GNU/Linux), dynamically linked,
interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=aae0a9a51c01e07511994ab36a0a6d4d2a645364, stripped
So, anybody experienced the same problem?
I can't tell you what's wrong on your end, but at least it doesn't seem
to be a general problem.
HTH,
Daniel
--
_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
