... 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 ```
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.
Thanks for your answer. I will take a look on the suggestions that you commented.