* [Buildroot] GLib/GObject-introspection bootstrap @ 2024-08-19 17:52 Fiona Klute via buildroot 2024-08-19 20:30 ` Yann E. MORIN 2024-08-19 22:16 ` Marcus Hoffmann via buildroot 0 siblings, 2 replies; 4+ messages in thread From: Fiona Klute via buildroot @ 2024-08-19 17:52 UTC (permalink / raw) To: buildroot; +Cc: Fabrice Fontaine Hi everyone, I'm currently trying to upgrade GLib & GObject-introspection to their current versions (1.80.4 and 1.80.1), not least because those work with musl without patching. The difficulty is that GLib now needs a sort of bootstrap process: * Build GLib with -Dintrospection=disabled * Build GObject-introspection * Build GLib with -Dintrospection=enabled Description in the GLib NEWS file: https://gitlab.gnome.org/GNOME/glib/-/blob/17d1bf3c4962d942feea0830aeee6833104fef5d/NEWS#L429-438 What would be the preferred way to implement this in Buildroot? Is there a built-in way to rebuild a package with different config after building another package for such situations? Or should I include that bootstrap build of GObject-introspection in libglib2.mk (like Alpine does)? In the latter case the GLib package would share the source archive with GObject-introspection and I remember reading on the ML that there's support for that, would be great if someone could point me at it if relevant. Also, when I prepare patches, should I just drop the glibc requirement for GObject-introspection, or add musl? I have no idea if it works with uClibc. Likewise, are the checks for (ancient) GCC versions still relevant? Best regards, Fiona _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Buildroot] GLib/GObject-introspection bootstrap 2024-08-19 17:52 [Buildroot] GLib/GObject-introspection bootstrap Fiona Klute via buildroot @ 2024-08-19 20:30 ` Yann E. MORIN 2024-08-21 13:38 ` Fiona Klute via buildroot 2024-08-19 22:16 ` Marcus Hoffmann via buildroot 1 sibling, 1 reply; 4+ messages in thread From: Yann E. MORIN @ 2024-08-19 20:30 UTC (permalink / raw) To: Fiona Klute; +Cc: Fabrice Fontaine, iMarcus Hoffmann, buildroot Fiona, All, +Marcus On 2024-08-19 19:52 +0200, Fiona Klute via buildroot spake thusly: > I'm currently trying to upgrade GLib & GObject-introspection to their > current versions (1.80.4 and 1.80.1), not least because those work with > musl without patching. Not a small task you started there... There was was some previous talks about that on IRC, but I haven't seen anything materialising so far... Marcus, are you still looking into that? So, for the records, here's my suggestion below... > The difficulty is that GLib now needs a sort of > bootstrap process: > > * Build GLib with -Dintrospection=disabled > * Build GObject-introspection > * Build GLib with -Dintrospection=enabled > > Description in the GLib NEWS file: > https://gitlab.gnome.org/GNOME/glib/-/blob/17d1bf3c4962d942feea0830aeee6833104fef5d/NEWS#L429-438 > > What would be the preferred way to implement this in Buildroot? Is there > a built-in way to rebuild a package with different config after building > another package for such situations? Or should I include that bootstrap > build of GObject-introspection in libglib2.mk (like Alpine does)? In the > latter case the GLib package would share the source archive with > GObject-introspection and I remember reading on the ML that there's > support for that, would be great if someone could point me at it if > relevant. So, the way to go would be to introduce a new package, libglib2-bootstrap, where the no-introspection libglib2 is built. Then GObject-introspectionGObject-GObject-introspection depends on libglib2-bootstrap. To share download, you'd tell libglib2-bootstrap to share its download with libglib2: LIBGLIB2_BOOTSTRAP_DL_SUBDIR = libglib2 Note that there is also the case for host-libglib2: do we need an introspection-aware host-libglib2, or can we do without it? If the former, then we'll need libglib2-bootstrap to also be a host package. > Also, when I prepare patches, should I just drop the glibc requirement > for GObject-introspection, or add musl? I have no idea if it works with > uClibc. Just add musl. > Likewise, are the checks for (ancient) GCC versions still relevant? Not sure what you meant here: libglib2 has no dependency on a gcc version. gobject-introspection does, however, and I doubt they would no longer be releveant; they may even be more stringent. Ypou'd have to check what libglib2 anf goi state they require. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Buildroot] GLib/GObject-introspection bootstrap 2024-08-19 20:30 ` Yann E. MORIN @ 2024-08-21 13:38 ` Fiona Klute via buildroot 0 siblings, 0 replies; 4+ messages in thread From: Fiona Klute via buildroot @ 2024-08-21 13:38 UTC (permalink / raw) To: Yann E. MORIN; +Cc: Fabrice Fontaine, Marcus Hoffmann, buildroot Yann, Marcus, thanks for your replies! Am 19.08.24 um 22:30 schrieb Yann E. MORIN: > Fiona, All, > > +Marcus > > On 2024-08-19 19:52 +0200, Fiona Klute via buildroot spake thusly: >> I'm currently trying to upgrade GLib & GObject-introspection to their >> current versions (1.80.4 and 1.80.1), not least because those work with >> musl without patching. > > Not a small task you started there... Thanks, it definitely looks like that... :-D > There was was some previous talks about that on IRC, but I haven't seen > anything materialising so far... Marcus, are you still looking into > that? You've probably seen Marcus' separate reply that sounds like a no, and also suggests a bootstrap package is the way to go. :-) > So, for the records, here's my suggestion below... > >> The difficulty is that GLib now needs a sort of >> bootstrap process: >> >> * Build GLib with -Dintrospection=disabled >> * Build GObject-introspection >> * Build GLib with -Dintrospection=enabled >> >> Description in the GLib NEWS file: >> https://gitlab.gnome.org/GNOME/glib/-/blob/17d1bf3c4962d942feea0830aeee6833104fef5d/NEWS#L429-438 >> >> What would be the preferred way to implement this in Buildroot? Is there >> a built-in way to rebuild a package with different config after building >> another package for such situations? Or should I include that bootstrap >> build of GObject-introspection in libglib2.mk (like Alpine does)? In the >> latter case the GLib package would share the source archive with >> GObject-introspection and I remember reading on the ML that there's >> support for that, would be great if someone could point me at it if >> relevant. > > So, the way to go would be to introduce a new package, > libglib2-bootstrap, where the no-introspection libglib2 is built. > > Then GObject-introspectionGObject-GObject-introspection depends on > libglib2-bootstrap. > > To share download, you'd tell libglib2-bootstrap to share its download > with libglib2: > LIBGLIB2_BOOTSTRAP_DL_SUBDIR = libglib2 > > Note that there is also the case for host-libglib2: do we need an > introspection-aware host-libglib2, or can we do without it? If the > former, then we'll need libglib2-bootstrap to also be a host package. That's a good question. In my builds so far I haven't had any issue with host-libglib2 without introspection, but of course it's possible *some* host package that's not part of my build (or a build that uses features I don't use) won't break. That said, having libglib2-bootstrap as a host package too seems to be the smallest part of extra complexity here, maybe even smaller than having libglib2 work with/without bootstrap depending on whether it's building for target or host. Is there a supported way for the packages to share Makefile definitions? In end LIBGLIB2_BOOTSTRAP_DL_SUBDIR and LIBGLIB2_CONF_OPTS/HOST_LIBGLIB2_CONF_OPTS should be the only real difference (I don't think it'd be very efficient to dig into what else we could disable in the bootstrap build). The host-go packages seem to have some shared code, but I didn't get to dig very deeply into that yet, so I don't know if that'd be a good example here. >> Also, when I prepare patches, should I just drop the glibc requirement >> for GObject-introspection, or add musl? I have no idea if it works with >> uClibc. > > Just add musl. Will do. >> Likewise, are the checks for (ancient) GCC versions still relevant? > > Not sure what you meant here: libglib2 has no dependency on a gcc > version. gobject-introspection does, however, and I doubt they would no > longer be releveant; they may even be more stringent. Ypou'd have to > check what libglib2 anf goi state they require. What I meant is "Is there any supported GCC 4.9 any more anyway, or is that check obsolete because any supported compiler version passes?" If you mean that we should require significantly newer versions you're probably correct, the changelog for GLib 2.81.0 [1] (so in the current dev release series) mentions that a C11 toolchain is strongly recommended now and will become required later, the linked MR mentions that C99 is currently required. Can I check/require that directly in Config.in, or would I need to look up which GCC version was the first to support a given C version? On additional detail question that I bumped into: GLib requires that target (or host, in Meson terms) binaries can be executed during the build when building with introspection. This can be solved with Qemu user mode: LIBGLIB2_MESON_EXTRA_BINARIES = \ exe_wrapper='$(QEMU_USER)' I have confirmed that build and resulting typelib files work in my aarch64 build. However, it ignores BR2_PACKAGE_HOST_QEMU_USER_MODE_ARGS, and the Meson documentation states that exe_wrapper must contain the binary path, there doesn't seem to be room for arguments. Is this sufficient, or would I have to introduce a wrapper script that adds the arguments? I'm also wondering if exe_wrapper might let us avoid the wrapper scripts currently set up by the gobject-introspection package, but if so I think that should be a separate patch series after GLib 2.80.x. ;-) Best regards, Fiona [1] https://gitlab.gnome.org/GNOME/glib/-/blob/3d53902fc39e0ecdd03e5088cd6e009872d62471/NEWS#L105-107 _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Buildroot] GLib/GObject-introspection bootstrap 2024-08-19 17:52 [Buildroot] GLib/GObject-introspection bootstrap Fiona Klute via buildroot 2024-08-19 20:30 ` Yann E. MORIN @ 2024-08-19 22:16 ` Marcus Hoffmann via buildroot 1 sibling, 0 replies; 4+ messages in thread From: Marcus Hoffmann via buildroot @ 2024-08-19 22:16 UTC (permalink / raw) To: Fiona Klute, buildroot; +Cc: Fabrice Fontaine Hi Fiona, I looked into this a few weeks back as well (but am unlikely to find time to continue working on this in the near future). The conclusion we came to on IRC was, that introducing a libglib2-initial package similar to gcc-initial would be the best/only option. (Which gets added as a dependency to gobject-introspection which then gets used to build the final libglib2.) I didn't actually get to trying this out, so no guarantees :). Best, Marcus On 19.08.24 19:52, Fiona Klute via buildroot wrote: > Hi everyone, > > I'm currently trying to upgrade GLib & GObject-introspection to their > current versions (1.80.4 and 1.80.1), not least because those work with > musl without patching. The difficulty is that GLib now needs a sort of > bootstrap process: > > * Build GLib with -Dintrospection=disabled > * Build GObject-introspection > * Build GLib with -Dintrospection=enabled > > Description in the GLib NEWS file: > https://gitlab.gnome.org/GNOME/glib/-/ > blob/17d1bf3c4962d942feea0830aeee6833104fef5d/NEWS#L429-438 > > What would be the preferred way to implement this in Buildroot? Is there > a built-in way to rebuild a package with different config after building > another package for such situations? Or should I include that bootstrap > build of GObject-introspection in libglib2.mk (like Alpine does)? In the > latter case the GLib package would share the source archive with > GObject-introspection and I remember reading on the ML that there's > support for that, would be great if someone could point me at it if > relevant. > > Also, when I prepare patches, should I just drop the glibc requirement > for GObject-introspection, or add musl? I have no idea if it works with > uClibc. Likewise, are the checks for (ancient) GCC versions still relevant? > > Best regards, > Fiona > > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-08-21 13:38 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-08-19 17:52 [Buildroot] GLib/GObject-introspection bootstrap Fiona Klute via buildroot 2024-08-19 20:30 ` Yann E. MORIN 2024-08-21 13:38 ` Fiona Klute via buildroot 2024-08-19 22:16 ` Marcus Hoffmann via buildroot
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.