[1/2] gobject-introspection: check for GI_DATA_ENABLED

From: Petr Kubizňák - 2N <kubiznak@2n.com>

When GI_DATA_ENABLED is 'False' (e.g. because
'gobject-introspection-data' is not in DISTRO_FEATURES),
gobject-introspection should not be added to DEPENDS.

Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
---
 meta/classes-recipe/gobject-introspection.bbclass | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

On Wed, 4 Jan 2023 at 12:46, Petr Kubizňák <kubiznak@2n.com> wrote:
> When GI_DATA_ENABLED is 'False' (e.g. because
> 'gobject-introspection-data' is not in DISTRO_FEATURES),
> gobject-introspection should not be added to DEPENDS.

Why?

Alex

I mean, if you want to do this to reduce dependency chains, then
depending on qemu-native and g-i-native isn't necessary either. But
the patch as it is seems like going halfway.

Alex

On Wed, 4 Jan 2023 at 12:54, Alexander Kanavin via
lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
wrote:
>
> On Wed, 4 Jan 2023 at 12:46, Petr Kubizňák <kubiznak@2n.com> wrote:
> > When GI_DATA_ENABLED is 'False' (e.g. because
> > 'gobject-introspection-data' is not in DISTRO_FEATURES),
> > gobject-introspection should not be added to DEPENDS.
>
> Why?
>
> Alex
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#175467): https://lists.openembedded.org/g/openembedded-core/message/175467
> Mute This Topic: https://lists.openembedded.org/mt/96048399/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Hi Alex,


Yes, that's exactly the reason. I'm particularly concerned about dependency on glib, but other dependencies are unnecessary, too.


This change was sufficient to remove the dependency from the target. I am not aware of potential consequences of removing the -native dependencies, but if you think it should also be done, I'm happy to update the patch. Please let me know.


Petr

On Wed, 4 Jan 2023 at 13:24, Petr Kubizňák <kubiznak@2n.com> wrote:
> Yes, that's exactly the reason. I'm particularly concerned about dependency on glib, but other dependencies are unnecessary, too.
>
>
> This change was sufficient to remove the dependency from the target. I am not aware of potential consequences of removing the -native dependencies, but if you think it should also be done, I'm happy to update the patch. Please let me know.

I'd suggest that you remove all three, then set up a plain poky master
build with gobject-introspection-data disabled, and issue bitbake
world.

Component upstreams generally only test the gi-enabled configuration,
so this may reveal incorrect upstream logic when g-i is disabled.

Alex

Is the `bitbake world` command guaranteed to succeed for every commit in the repository? In my case, I end up with failures even with _default_ setup. My point is whether this has to be an issue on my machine (e.g. native tools?), or I should just try a different commit.


Build Configuration:
BB_VERSION           = "2.2.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "x86_64-poky-linux"
MACHINE              = "qemux86-64"
DISTRO               = "poky"
DISTRO_VERSION       = "4.1"
TUNE_FEATURES        = "m64 core2"
TARGET_FPU           = ""
meta
meta-poky
meta-yocto-bsp       = "HEAD:2c6f0b9228b47459dd1b67d578792cd017006128"
...
ERROR: rust-1.66.0-r0 do_compile: ExecutionError('/home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/temp/run.do_compile.1080378', 1, None, None)
ERROR: Logfile of failure stored in: /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/temp/log.do_compile.1080378
NOTE: recipe rust-1.66.0-r0: task do_compile: Failed
ERROR: Task (/home/kubiznak/projects/poky/meta/recipes-devtools/rust/rust_1.66.0.bb:do_compile) failed with exit code '1'

The first error in rust log:

error: /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/rustc-1.66.0-src/build/x86_64-unknown-linux-gnu/stage1-rustc/release/deps/libunic_langid_macros_impl-09018f99e8b09dcb.so: undefined symbol: _Ungind_Resume
 --> /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/rustc-1.66.0-src/vendor/unic-langid-macros/src/lib.rs:5:9
  |
5 | pub use unic_langid_macros_impl::langid;
  |         ^^^^^^^^^^^^^^^^^^^^^^^

Full logs attached.


Petr

We do run world on every master tip, so yes it should succeed. It
doesn't seem to be related to disabling introspection, but you might
want to retry with it enabled to be sure.

If target rust continues to fail no matter what you try, then 'bitbake
-k world' will continue building what it can when fails occur.

Alex

On Thu, 5 Jan 2023 at 15:13, Petr Kubizňák <kubiznak@2n.com> wrote:
>
> Is the `bitbake world` command guaranteed to succeed for every commit in the repository? In my case, I end up with failures even with _default_ setup. My point is whether this has to be an issue on my machine (e.g. native tools?), or I should just try a different commit.
>
>
> Build Configuration:
> BB_VERSION           = "2.2.0"
> BUILD_SYS            = "x86_64-linux"
> NATIVELSBSTRING      = "universal"
> TARGET_SYS           = "x86_64-poky-linux"
> MACHINE              = "qemux86-64"
> DISTRO               = "poky"
> DISTRO_VERSION       = "4.1"
> TUNE_FEATURES        = "m64 core2"
> TARGET_FPU           = ""
> meta
> meta-poky
> meta-yocto-bsp       = "HEAD:2c6f0b9228b47459dd1b67d578792cd017006128"
> ...
> ERROR: rust-1.66.0-r0 do_compile: ExecutionError('/home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/temp/run.do_compile.1080378', 1, None, None)
> ERROR: Logfile of failure stored in: /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/temp/log.do_compile.1080378
> NOTE: recipe rust-1.66.0-r0: task do_compile: Failed
> ERROR: Task (/home/kubiznak/projects/poky/meta/recipes-devtools/rust/rust_1.66.0.bb:do_compile) failed with exit code '1'
>
> The first error in rust log:
>
> error: /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/rustc-1.66.0-src/build/x86_64-unknown-linux-gnu/stage1-rustc/release/deps/libunic_langid_macros_impl-09018f99e8b09dcb.so: undefined symbol: _Ungind_Resume
>  --> /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/rustc-1.66.0-src/vendor/unic-langid-macros/src/lib.rs:5:9
>   |
> 5 | pub use unic_langid_macros_impl::langid;
>   |         ^^^^^^^^^^^^^^^^^^^^^^^
>
> Full logs attached.
>
>
> Petr
>
> ________________________________
> From: Alexander Kanavin <alex.kanavin@gmail.com>
> Sent: Wednesday, January 4, 2023 1:36:27 PM
> To: Petr Kubizňák - 2N
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core][PATCH 1/2] gobject-introspection: check for GI_DATA_ENABLED
>
> On Wed, 4 Jan 2023 at 13:24, Petr Kubizňák <kubiznak@2n.com> wrote:
> > Yes, that's exactly the reason. I'm particularly concerned about dependency on glib, but other dependencies are unnecessary, too.
> >
> >
> > This change was sufficient to remove the dependency from the target. I am not aware of potential consequences of removing the -native dependencies, but if you think it should also be done, I'm happy to update the patch. Please let me know.
>
> I'd suggest that you remove all three, then set up a plain poky master
> build with gobject-introspection-data disabled, and issue bitbake
> world.
>
> Component upstreams generally only test the gi-enabled configuration,
> so this may reveal incorrect upstream logic when g-i is disabled.
>
> Alex
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#175529): https://lists.openembedded.org/g/openembedded-core/message/175529
> Mute This Topic: https://lists.openembedded.org/mt/96048399/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

rust_1.66.0 and webkitgtk_2.38.2 keep failing to build in any setup (including g-i enabled and no patch applied) on my side.


What's more interesting, with no patch applied and g-i disabled, graphene_1.10.8 fails to build ("Failed to parse included gir GObject-2.0").


When the patch is _applied_ and g-i is _disabled_, graphene does build, but some other packages don't:


gconf_3.2.6.bb:do_configure:
/home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/gconf/3.2.6-r0/temp/run.do_configure.2180034: 225: glib-gettextize: not found


python3-pygobject_3.42.2.bb:do_configure:

Run-time dependency gobject-introspection-1.0 found: NO (tried pkgconfig and cmake)

Looking for a fallback subproject for the dependency gobject-introspection-1.0
../pygobject-3.42.2/meson.build:29:0: ERROR: Automatic wrap-based subproject downloading is disabled

avahi_0.8.bb:do_compile:
/bin/bash: line 2: glib-mkenums: command not found

gtk4_4.8.2.bb:do_configure:
Run-time dependency graphene-gobject-1.0 found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency graphene-gobject-1.0
../gtk-4.8.2/meson.build:440:0: ERROR: Automatic wrap-based subproject downloading is disabled


This shows that these packages depend on gobject-introspection and/or its dependencies no matter whether introspection is enabled or disabled. I don't know these packages so I don't think I'm able to patch them properly. On the other hand, I still believe it is incorrect to pull in the unnecessary dependencies when g-i is disabled. What do you think?


Petr

On Fri, 6 Jan 2023 at 19:52, Petr Kubizňák <kubiznak@2n.com> wrote:
> When the patch is _applied_ and g-i is _disabled_, graphene does build, but some other packages don't:

...

> This shows that these packages depend on gobject-introspection and/or its dependencies no matter whether introspection is enabled or disabled. I don't know these packages so I don't think I'm able to patch them properly. On the other hand, I still believe it is incorrect to pull in the unnecessary dependencies when g-i is disabled. What do you think?
>

This is what I was worried about. It uncovers a whole list of
failures, and creates a new maintenance burden going forward, as
fixing them will be an ongoing activity in the absence of an
unconditional g-i dependecy..

If you have a bit of time, I'd suggest that you check the failures one
by one. Some of it, like missing glib-* executables seems like a
trivial missing dependency which was previously pulled in indirectly.
Others, like python3-pygobject probably have a hard dependency on g-i.

It does require navigating your way around unfamiliar source code,
which is a useful skill in yocto regardless.

Alex

If you have a bit of time, I'd suggest that you check the failures one
by one. Some of it, like missing glib-* executables seems like a
trivial missing dependency which was previously pulled in indirectly.
Others, like python3-pygobject probably have a hard dependency on g-i.
I'm slowly progressing with the patch but always end up at the principal issue of hard dependency on g-i being enabled.

For example, graphene recipe does not reflect on "gobject-introspection-data" being/not being in distro features, claiming gtk4 requires build with introspection. Graphene can be patched to be buildable under both circumstances but gtk4 then (unsurprisingly) fails in do_configure step due to missing graphene-gobject-1.0 if g-i is disabled.

I don't think gtk4 can be patched to build with g-i disabled, do you?

If you agree with me, how can we proceed with the fact that some packages (namely gtk4) basically cannot be built without the feature, while still allowing to disable that feature? Is it really necessary to have everything buildable with g-i disabled? Apparently, it's not buildable now.

Petr

On Thu, Jan 5, 2023 at 2:13 PM Petr Kubizňák <kubiznak@2n.com> wrote:
>
> Is the `bitbake world` command guaranteed to succeed for every commit in the repository? In my case, I end up with failures even with _default_ setup. My point is whether this has to be an issue on my machine (e.g. native tools?), or I should just try a different commit.
>
>
> Build Configuration:
> BB_VERSION           = "2.2.0"
> BUILD_SYS            = "x86_64-linux"
> NATIVELSBSTRING      = "universal"
> TARGET_SYS           = "x86_64-poky-linux"
> MACHINE              = "qemux86-64"
> DISTRO               = "poky"
> DISTRO_VERSION       = "4.1"
> TUNE_FEATURES        = "m64 core2"
> TARGET_FPU           = ""
> meta
> meta-poky
> meta-yocto-bsp       = "HEAD:2c6f0b9228b47459dd1b67d578792cd017006128"
> ...
> ERROR: rust-1.66.0-r0 do_compile: ExecutionError('/home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/temp/run.do_compile.1080378', 1, None, None)
> ERROR: Logfile of failure stored in: /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/temp/log.do_compile.1080378
> NOTE: recipe rust-1.66.0-r0: task do_compile: Failed
> ERROR: Task (/home/kubiznak/projects/poky/meta/recipes-devtools/rust/rust_1.66.0.bb:do_compile) failed with exit code '1'
>
> The first error in rust log:
>
> error: /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/rustc-1.66.0-src/build/x86_64-unknown-linux-gnu/stage1-rustc/release/deps/libunic_langid_macros_impl-09018f99e8b09dcb.so: undefined symbol: _Ungind_Resume
>  --> /home/kubiznak/projects/poky/builds/test-gi/tmp/work/core2-64-poky-linux/rust/1.66.0-r0/rustc-1.66.0-src/vendor/unic-langid-macros/src/lib.rs:5:9
>   |
> 5 | pub use unic_langid_macros_impl::langid;
>   |         ^^^^^^^^^^^^^^^^^^^^^^^
>

Are you building with `DEBUG_BUILD = "1"`? There seem to be a number
of tickets out there for this failure if the optimiser isn't running.

> Full logs attached.
>
>
> Petr
>
> ________________________________
> From: Alexander Kanavin <alex.kanavin@gmail.com>
> Sent: Wednesday, January 4, 2023 1:36:27 PM
> To: Petr Kubizňák - 2N
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core][PATCH 1/2] gobject-introspection: check for GI_DATA_ENABLED
>
> On Wed, 4 Jan 2023 at 13:24, Petr Kubizňák <kubiznak@2n.com> wrote:
> > Yes, that's exactly the reason. I'm particularly concerned about dependency on glib, but other dependencies are unnecessary, too.
> >
> >
> > This change was sufficient to remove the dependency from the target. I am not aware of potential consequences of removing the -native dependencies, but if you think it should also be done, I'm happy to update the patch. Please let me know.
>
> I'd suggest that you remove all three, then set up a plain poky master
> build with gobject-introspection-data disabled, and issue bitbake
> world.
>
> Component upstreams generally only test the gi-enabled configuration,
> so this may reveal incorrect upstream logic when g-i is disabled.
>
> Alex
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#175529): https://lists.openembedded.org/g/openembedded-core/message/175529
> Mute This Topic: https://lists.openembedded.org/mt/96048399/3618097
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kiernan@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

This issue was actually caused by missing host dependencies. Shame on me...

On Tue, 17 Jan 2023 at 11:57, Petr Kubizňák <kubiznak@2n.com> wrote:
> I'm slowly progressing with the patch but always end up at the principal issue of hard dependency on g-i being enabled.
>
> For example, graphene recipe does not reflect on "gobject-introspection-data" being/not being in distro features, claiming gtk4 requires build with introspection. Graphene can be patched to be buildable under both circumstances but gtk4 then (unsurprisingly) fails in do_configure step due to missing graphene-gobject-1.0 if g-i is disabled.
>
> I don't think gtk4 can be patched to build with g-i disabled, do you?
>
> If you agree with me, how can we proceed with the fact that some packages (namely gtk4) basically cannot be built without the feature, while still allowing to disable that feature? Is it really necessary to have everything buildable with g-i disabled? Apparently, it's not buildable now.

It helps if you show the errors you are getting, and source code lines
they are coming from, so I do not have to guess what is happening or
dig around source code.

The way I read gtk4 and graphene source code, what the recipe claims
is not true: you can disable introspection in graphene, and it would
still build and install graphene-gobject.pc which is what gtk4 is
looking for. If the needed piece is not installed, then you need to
get to the bottom of why, e.g. specific source code lines where that
decision is made.

Alex

On 2023-01-17 07:58, Petr Kubizňák via lists.openembedded.org wrote:
> This issue was actually caused by missing host dependencies. Shame on me...

Do you mean standard host dependencies from our documented list:
 
https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html#build-host-packages
?

Hi Alex,

May I kindly ask you for your opinion?

Thank you,
Petr

On Wed, 15 Feb 2023 at 10:39, Petr Kubizňák - 2N <Kubiznak@2n.com> wrote:
> > The way I read gtk4 and graphene source code, what the recipe claims
> > is not true: you can disable introspection in graphene, and it would
> > still build and install graphene-gobject.pc which is what gtk4 is
> > looking for. If the needed piece is not installed, then you need to
> > get to the bottom of why, e.g. specific source code lines where that
> > decision is made.
>
> That's not really true. If no patches are applied and g-i is disabled, graphene fails in do_compile:
>
> [75/75] /home/kubiznak/projects/poky2/build/tmp/work/core2-64-poky-linux/graphene/1.10.8-r0/recipe-sysroot/usr/bin/g-ir-compiler-wrapper src/Graphene-1.0.gir --output src/Graphene-1.0.typelib --includedir=/usr/share/gir-1.0
> FAILED: src/Graphene-1.0.typelib
> /home/kubiznak/projects/poky2/build/tmp/work/core2-64-poky-linux/graphene/1.10.8-r0/recipe-sysroot/usr/bin/g-ir-compiler-wrapper src/Graphene-1.0.gir --output src/Graphene-1.0.typelib --includedir=/usr/share/gir-1.0
> Could not find GIR file 'GObject-2.0.gir'; check XDG_DATA_DIRS or use --includedir
> error parsing file src/Graphene-1.0.gir: Failed to parse included gir GObject-2.0

I replicated this locally. graphene isn't being correctly configured
when introspection is disabled globally, and the attached patch is
correct. Can you resend it as a proper oe-core submission?

I haven't seen webkit fail like that before, and it does not fail for
me locally this way.

Alex