Bug 241030
| Summary: | [GTK][WPE] Error cross-compiling for a different target than the build host using the -DENABLE_INTROSPECTION=ON flag. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Pablo Saavedra <psaavedra> |
| Component: | CMake | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | aperez |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Pablo Saavedra
... in a cross-compilation setup, there is a deadlock leading in a build failure when -DENABLE_INTROSPECTION=ON:
* Fail 1: The CMake rules find the g-ir-scanner in the Target rootfs of the toolchain. Then execution fails because the binary is not a binary of the host architecture:
```
Traceback (most recent call last):
File "tmp/work/cortexa9t2hf-neon-imx-poky-linux-gnueabi/wpewebkit/trunk+https999-r0/recipe-sysroot/usr/bin/g-ir-scanner", line 98, in <module>
from giscanner.scannermain import scanner_main
File "tmp/work/cortexa9t2hf-neon-imx-poky-linux-gnueabi/wpewebkit/trunk+https999-r0/recipe-sysroot/usr/lib/gobject-introspection/giscanner/scannermain.py", line 35, in <module>
from giscanner.ast import Include, Namespace
File "tmp/work/cortexa9t2hf-neon-imx-poky-linux-gnueabi/wpewebkit/trunk+https999-r0/recipe-sysroot/usr/lib/gobject-introspection/giscanner/ast.py", line 29, in <module>
from .sourcescanner import CTYPE_TYPEDEF, CSYMBOL_TYPE_TYPEDEF
File "tmp/work/cortexa9t2hf-neon-imx-poky-linux-gnueabi/wpewebkit/trunk+https999-r0/recipe-sysroot/usr/lib/gobject-introspection/giscanner/sourcescanner.py", line 34, in <module>
from giscanner._giscanner import SourceScanner as CSourceScanner
ImportError: tmp/work/cortexa9t2hf-neon-imx-poky-linux-gnueabi/wpewebkit/trunk+https999-r0/recipe-sysroot/usr/lib/gobject-introspection/giscanner/_giscanner.cpython-39-x86_64-linux-gnu.so: wrong ELF class: ELFCLASS32
```
Fail 2: The CMake rules find the g-ir-scanner in the native sysrootfs for the build host but this fails during the execution because the WPEWebKit-1.0 library is built for the target architecture
```
tmp/work/cortexa9t2hf-neon-imx-poky-linux-gnueabi/wpewebkit/trunk+https999-r0/recipe-sysroot-native/usr/bin/g-ir-scanner --quiet --warn-all --warn-error --no-libtool --output=tmp/work/cortexa9t2hf-neon-imx-poky-linux-gnueabi/wpewebkit/trunk+https999-r0/wpewebkit-trunk+https999/WPEJavaScriptCore-1.0.gir --library=WPEWebKit-1.0 --library-path=tmp/work/cortexa9t2hf-neon-imx-poky-linux-gnueabi/wpewebkit/trunk+https999-r0/wpewebkit-trunk+https999/lib --namespace=WPEJavaScriptCore --nsversion=1.0 --c-include=jsc/jsc.h --identifier-prefix=JSC --symbol-prefix=jsc --pkg-export=wpe-javascriptcore-1.0 -DBUILDING_WebKit -DBUILDING_WITH_CMAKE=1 -DHAVE_CONFIG_H=1 -DPAS_BMALLOC=1 -DBUILDING_WPE__=1 -DGETTEXT_PACKAGE=\"WPE\" -DJSC_GLIB_API_ENABLED -DWEBKIT2_COMPILATION -DLIBDIR=\"/usr/lib\" -DPKGLIBDIR=\"/usr/lib/wpe-webkit-1.0\" -DPKGLIBEXECDIR=\"/usr/libexec/wpe-webkit-1.0\" -DDATADIR=\"/usr/share\" -DLOCALEDIR=\"/usr/share/locale\" -DSTATICALLY_LINKED_WITH_JavaScriptCore -DSTATICALLY_LINKED_WITH_WTF -DSTATICALLY_LINKED_WITH_bmalloc -DSTATICALLY_LINKED_WITH_PAL -DSTATICALLY_LINKED_WITH_WebCore ... workspace/sources/wpewebkit/Source/JavaScriptCore/API/glib/JSCWrapperMap.cpp
ERROR: can't resolve libraries to shared libraries: WPEWebKit-1.0
```
Related commit:
```
commit b0ae032850bb6b2672051bab8032fc9f9ef5eb97
Author: Adrian Perez de Castro <aperez@igalia.com>
Date: Sat Apr 2 10:57:15 2022 +0000
[GTK] Replace gtk-doc with gi-docgen
https://bugs.webkit.org/show_bug.cgi?id=226662
```
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Adrian Perez
This is expected. Running “g-ir-scanner” compiles and *runs* a program
which is used to generate the introspection data. The generated data
is architecture-dependant: the program has to run in the target architecture.
Nevertheless, it is possible to get things working. What cross-build
systems like Yocto and Buildroot do these days is using qemu user space
emulation to run the program generated by “g-ir-scanner”. In the case
of Yocto there is a .bbclass here:
https://github.com/openembedded/openembedded-core/blob/master/meta/classes/gobject-introspection.bbclass
Buildroot has wrapper scripts for host-gobject-introspection, for
example:
https://git.busybox.net/buildroot/tree/package/gobject-introspection/g-ir-scanner-qemuwrapper.in
Therefore I think there is nothing we should do on our end:
- Users doing an cross-build by hand can disable documentation and
introspection (because of bug #226662 now gi-docgen also needs
to run g-ir-scanner).
- Cross-compilations systems have already figured out how to handle
gobject-introspection.
Pablo Saavedra
Thanks for your answer. I will take a look on the suggestions that you commented.