[Buildroot] GLib/GObject-introspection bootstrap

[Buildroot] GLib/GObject-introspection bootstrap

[Fiona Klute via buildroot]

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

Re: [Buildroot] GLib/GObject-introspection bootstrap

[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...

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

Re: [Buildroot] GLib/GObject-introspection bootstrap

[Marcus Hoffmann via buildroot]

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

Re: [Buildroot] GLib/GObject-introspection bootstrap

[Fiona Klute via 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