1773336 - gkrust fails to link with error: 'undefined reference todbus_message_iter_init_append'

Status: RESOLVED MOVED

(Core :: Graphics: WebRender, defect)

Description

[tt_1]

Attachment: firefox-nightly-fails-to-link.xz

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

I downloaded latest github sources and compiled them

Actual results:

the build compiles but fails to link with hundreds of missing references to dbus, such as these:

46:42.84 /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: /var/tmp/portage/portage/www-client/firefox-103.0/work/firefox_build/thumbv7neon-unknown-linux-gnueabihf/release/libgkrust.a(gkrust-7538eec08ad8b394.gkrust.4bef9555-cgu.0.rcgu.o): in function audio_thread_priority::rt_linux::promote_thread_to_real_time_internal': 46:42.85 gkrust.4bef9555-cgu.0:(.text._ZN21audio_thread_priority8rt_linux36promote_thread_to_real_time_internal17h7aeb882900ca173aE+0x11e): undefined reference to dbus_message_iter_init_append'

Expected results:

I expect the compiled sources to link without errors.

this is somewhat of a reoccurance of https://bugzilla.mozilla.org/show_bug.cgi?id=1761691 ; but that has been fixed in the past.

last successfull compile of the nightly branch with --disable-dbus was June 2nd - possible a new regression by 1773070

the compressed build log is attached

Comment 1

[Emilio Cobos Álvarez [:emilio]]

That regression range wouldn't make sense. That patch doesn't change how any symbol is linked, nor anything remotely related to dbus.

Can you bisect?

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[tt_1]

I'm trying to run a binary search through the commits of the last 24hrs, but it takes one hour per try on my machine.

I can say for now that the commit that includes the fix for 1773070 is affected

Comment 4

[tt_1]

there is an underlying error prior to 1773070:

1:20.86 In file included from /var/tmp/portage/portage/www-client/firefox-103.0/work/firefox_build/dist/include/mozilla/webrender/webrender_ffi.h:104,
1:20.86 /var/tmp/portage/portage/www-client/firefox-103.0/work/firefox_build/dist/include/mozilla/webrender/webrender_ffi_generated.h:24:33: error: redefinition of 'constexpr const uint64_t mozilla::wr::ROOT_CLIP_CHAIN'

it has been fixed in head of git (compressed log doesn't show it), but I'm having a difficult time with finding the regression if problems overlap in this way.

Comment 5

[Emilio Cobos Álvarez [:emilio]]

You can just remove that definition from webrender_ffi.h.

Comment 6

[Mike Hommey [:glandium]]

in function audio_thread_priority::rt_linux::promote_thread_to_real_time_internal'

That comes from https://github.com/kinetiknz/audioipc/pull/5/
A new version of audioipc with that fix is going to be pulled sometime soon, probably tomorrow.

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Great, so this is a dupe of https://github.com/kinetiknz/audioipc/pull/5/.

Martin, the build error you're seeing is for building an older revision with a newer cbindgen (which is able to generate the ROOT_CLIP_CHAIN definition itself). Removing the manual definition from webrender_ffi.h should fix it.

Comment 8

[tt_1]

indeed, the update for audiopic solves the initially reported issue

Comment 9

[tt_1]

so what is the best option for the underlying build error, caused by new cbindgen-0.24.2 binary?

this bug wasn't initally about it, but was renamed accordingly?

shall I reopen this one, or open another one?

Comment 10

[Emilio Cobos Álvarez [:emilio]]

Just remove the constant from webrender_ffi.h, or use an older cbindgen? Trunk builds with the newer cbindgen already.

Comment 11

[tt_1]

so there is a fix for this in the upstream audioipc as of now, will the update be pulled in soon?

There is now 103 beta branch affected

Comment 12

[Emilio Cobos Álvarez [:emilio]]

301 for the audioipc question, I don't know what the fix is here?

Comment 13

[tt_1]

no idea what you mean by 301

the fix is to update audioipc to inherit this pullrequest: https://github.com/kinetiknz/audioipc/pull/5/

situation is a bit confusing, seems that the mozilla fork has to be synced, and then this synced fork has to be pushed to the source tree

Comment 14

[tt_1]

hey Mike, do you have any idea why your very much welcome fix from https://github.com/kinetiknz/audioipc/pull/5/ does not get pulled into the firefox source code tree? firefox-103.0 and newer are affected by this.

Comment 15

[Matthew Gregan [:kinetik]]

(In reply to tt_1 from comment #14)

hey Mike, do you have any idea why your very much welcome fix from https://github.com/kinetiknz/audioipc/pull/5/ does not get pulled into the firefox source code tree? firefox-103.0 and newer are affected by this.

It'll land via bug 1781993 shortly. Sorry about the delay!