11aa1cfa5a
There are a lot of interconnected changes in these releases: Since 2.79.0, the introspection (i11n) data for libglib2 was moved out of gobject-introspection (GOI) and into libglib2 itself, thus building libglib2 with i11n needs tools provided by GOI [0]. However, GOI needs libglib2, but it is content with a libglib2 that does not have i11n. So we introduce a new package, libglib2-bootstrap, that provides a minimalist libglib2 that is enough to build GOI, build GOI, then build the final, complete libglib2 with i11n. However, not every package needs i11n, so we make that optional: if GOI is enabled, libglib2 will have i11n, otherwise it won't. This means the dependency ordering has changed: GOI used to build-depend on libglib2, but now that's the other way around. This will cause issues with packages that build-depend only on GOI and then expect a libglib2 with i11n; those will only get a basic libglib2 without i11n at build time, but a full one at runtime. Those packages will have to be fixed to also include a build dependency on libglib2. The version bump between libglib2 and GOI must be done in lock-step, because newer GOI does not support an older libglib2 and, as seen above, newer libglib2 has the data previously provided by older GOI. As a consequence of now generating its own i11n data, libglib2 needs to be able to run target programs during the build, to extract data layout and generate i11n data, a bit like GOI does [1]. So we provide a qemu wrapper similar to the one in nodejs-src, and use that as meson's exe_wrapper. Except for our first patch, the other libglib2 patches were backports, and are present upstream already, so we can drop them; the first patch needs being refreshed. We also move the remaining patch to a versioned sub-directory, so that it is easier to share the patches between libglib2-bootstrap and libglib2, should we need to add more patches in the future. Drop the "giscanner: remove dependency on distutils.msvccompile" patch, included upstream. Updated hash for giscanner/scannerlexer.l is due to code changes, no change in license, see [2] (two commits in 2024). [0] https://gitlab.gnome.org/GNOME/glib/-/blob/2.79.0/NEWS?ref_type=tags#L8-17 [1] technically, this should not be needed if libglib2 only uses the wrappers provided by GOI: g-ir-scanner et al. However, its meson.build explicitly checks that it can run generated binaries through the exe_wrapper. Investigating if that's really needed is left as an exercise for the interested party: in practice, we will have to be able to run via host-qemu, so this does not add any build time overhead. [2] https://gitlab.gnome.org/GNOME/gobject-introspection/-/commits/1.82.0/giscanner/scannerlexer.l?ref_type=tags Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Tested-by: Marcus Hoffmann <buildroot@bubu1.eu> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
10 lines
316 B
Bash
10 lines
316 B
Bash
#!/usr/bin/env sh
|
|
|
|
# Pass -r to qemu-user as to trick glibc into not erroring out if the host kernel
|
|
# is older than the target kernel.
|
|
exec @QEMU_USER@ -r @TOOLCHAIN_HEADERS_VERSION@ \
|
|
@QEMU_USERMODE_ARGS@ \
|
|
-L "${STAGING_DIR}/" \
|
|
-E LD_LIBRARY_PATH="${STAGING_DIR}/lib:${STAGING_DIR}/usr/lib/" \
|
|
"$@"
|