1830040 - nICEr fails to build on musl libc

Status: RESOLVED FIXED

(Core :: WebRTC, defect)

Description

[yuka]

Steps to reproduce:

Build Firefox on a system with musl libc

Actual results:

In file included from Unified_c_third_party_nICEr1.c:20:
In file included from /build/firefox-112.0.2/dom/media/webrtc/transport/third_party/nICEr/src/stun/addrs-netlink.c:49:
In file included from /build/firefox-112.0.2/mozobj/dist/system_wrappers/net/if.h:3:
/nix/store/jlghgxdf4wglvxyvca1c5p3zvhd7h865-musl-1.2.3-dev/include/net/if.h:64:8: error: redefinition of 'ifmap'
struct ifmap {
       ^
/nix/store/jlghgxdf4wglvxyvca1c5p3zvhd7h865-musl-1.2.3-dev/include/linux/if.h:194:8: note: previous definition is here
struct ifmap {
       ^
In file included from Unified_c_third_party_nICEr1.c:20:
In file included from /build/firefox-112.0.2/dom/media/webrtc/transport/third_party/nICEr/src/stun/addrs-netlink.c:49:
In file included from /build/firefox-112.0.2/mozobj/dist/system_wrappers/net/if.h:3:
/nix/store/jlghgxdf4wglvxyvca1c5p3zvhd7h865-musl-1.2.3-dev/include/net/if.h:76:8: error: redefinition of 'ifreq'
struct ifreq {
       ^
/nix/store/jlghgxdf4wglvxyvca1c5p3zvhd7h865-musl-1.2.3-dev/include/linux/if.h:232:8: note: previous definition is here
struct ifreq {
       ^
In file included from Unified_c_third_party_nICEr1.c:20:
In file included from /build/firefox-112.0.2/dom/media/webrtc/transport/third_party/nICEr/src/stun/addrs-netlink.c:49:
In file included from /build/firefox-112.0.2/mozobj/dist/system_wrappers/net/if.h:3:
/nix/store/jlghgxdf4wglvxyvca1c5p3zvhd7h865-musl-1.2.3-dev/include/net/if.h:116:8: error: redefinition of 'ifconf'
struct ifconf {
       ^
/nix/store/jlghgxdf4wglvxyvca1c5p3zvhd7h865-musl-1.2.3-dev/include/linux/if.h:284:8: note: previous definition is here
struct ifconf  {
       ^
3 errors generated.
make[3]: *** [/build/firefox-112.0.2/config/rules.mk:585: Unified_c_third_party_nICEr1.o] Error 1
make[3]: Leaving directory '/build/firefox-112.0.2/mozobj/dom/media/webrtc/transport/third_party/nICEr/nicer_nicer'
make[2]: *** [/build/firefox-112.0.2/config/recurse.mk:72: dom/media/webrtc/transport/third_party/nICEr/nicer_nicer/target-objects] Error 2
make[2]: *** Waiting for unfinished jobs....

Expected results:

This code should be portable and compile on musl libc without errors

Comment 1

[yuka]

Please assign me to this bug

Comment 2

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

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

Comment 3

[vcunat]

Workaround of interest:
https://git.alpinelinux.org/aports/plain/community/firefox/avoid-redefinition.patch?id=2f620d205ed0f9072bbd7714b5ec1b7bf6911c12

Comment 4

[Byron Campen [:bwc]]

(In reply to yuka from comment #1)

Please assign me to this bug

Sure! If you are not already familiar with the workflow for submitting a patch, the documentation is here:

https://firefox-source-docs.mozilla.org/contributing/how_to_submit_a_patch.html

Comment 5

[alice]

to be specific on how the workaround works, <linux/if.h> contains things like:

/* for compatibility with glibc net/if.h */
#if __UAPI_DEF_IF_IFREQ

and so musl's <net/if.h> contains:

#define __UAPI_DEF_IF_IFREQ 0

to allow it to prevent this clash, if you include it first.

i tried looking at how glibc is not vulnerable to this, but honestly after following like 6 headers in a row i got lost. the source does not even contain strings like __UAPI_DEF_IF_IFREQ, so i have no idea what they're really doing to avoid redefines.

Comment 6

[yuka]

Attachment: Bug 1830040 - Move net/if.h include before linux/if.h

To fix redefinition error when building against musl libc

Comment 7

[Byron Campen [:bwc]]

I'm guessing you do not yet have try access? If not, I can go ahead and set up a try push for you.

Comment 8

[yuka]

Indeed I do not have access.

I can go ahead and set up a try push for you.

Please do that.

Comment 9

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/jobs?repo=try&revision=0dc65ff690ef914fc4d5e38af0ad963f34ce7bfe
https://treeherder.mozilla.org/jobs?repo=try&revision=b898ec47b5273420019d505f6b6f32b0fd7c3a9a
https://treeherder.mozilla.org/jobs?repo=try&revision=66e932051f3c0ecc2bf02a53fb093c053d5b4c6c

Comment 10

[Byron Campen [:bwc]]

mochitest/crashtest/gtest look fine, but the wpt try run flaked out on us due to other issues. Here's another wpt try run:

https://treeherder.mozilla.org/jobs?repo=try&revision=f4e49934cd2b15c1c7bbc86fb101aeb62323ed68

Comment 11

[Byron Campen [:bwc]]

Ok... wpt try flaked again. Third time's the charm?

https://treeherder.mozilla.org/jobs?repo=try&revision=67c7f81f9927c4b5d1906a20a72be5d18ff258f5

Comment 12

[Byron Campen [:bwc]]

...nope. Any idea why the Gecko Decision Task is permabusted for this wpt push?

Comment 13

[Byron Campen [:bwc]]

I'm just going to land this. The probability that this particular change would be totally fine for mochitest/crashtest/gtest, but not wpt, is extremely low.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cddb250a28d8
Move net/if.h include before linux/if.h r=bwc

Comment 15

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/cddb250a28d8

Comment 16

[Byron Campen [:bwc]]

Thanks for the patch!

Comment 17

[Andrew Halberstadt [:ahal]]

Thanks for the link, this looks like a recent regression that likely only triggers under certain circumstances.

Hey Joel, you'll probably want to look into the following log:
https://firefox-ci-tc.services.mozilla.com/tasks/RDUPA16xRV-Jcbc8snDCMg/runs/0/logs/public/logs/live.log

Comment 18

[Joel Maher ( :jmaher ) (UTC -8) (PTO back normal Nov 17)]

ah, I think I have a fix for this in bug 1830520