1566938 - The check_networking build system test prevents writing Rust networking code for use in gecko

Status: RESOLVED INVALID

(Firefox Build System :: General, enhancement)

Description

[Dan Minor [:dminor]]

As per https://bugzilla.mozilla.org/show_bug.cgi?id=1376621#c30, this bug tracks that the following calls: bind, getaddrinfo, recvfrom, sendto, setsockopt, socket were removed from the check_networking test to allow for their use by the Rust mDNS responder, which is being developed over in Bug 1554976.

Comment 1

[Mike Hommey [:glandium]]

You might as well say you want to disable check_networking entirely, which is close to what you're asking for. And I don't think that is the right approach.

Considering bug 1554976 seems to be about adding rust backend code for webrtc, it would imply that rust code is not used for anything else, especially not other rust code.

So it seems to me what you're looking for is to build a separate rust library, and link that to libxul. And to not run check_networking on that library, still leaving it to run on libgkrust.

Comment 2

[Dan Minor [:dminor]]

(In reply to Mike Hommey [:glandium] from comment #1)

You might as well say you want to disable check_networking entirely, which is close to what you're asking for. And I don't think that is the right approach.

Considering bug 1554976 seems to be about adding rust backend code for webrtc, it would imply that rust code is not used for anything else, especially not other rust code.

So it seems to me what you're looking for is to build a separate rust library, and link that to libxul. And to not run check_networking on that library, still leaving it to run on libgkrust.

That does seem like the better approach. Any guidance / examples on how I would accomplish this? The current docs on adding Rust code seem to point to putting everything in libgkrust.

Comment 3

[Mike Hommey [:glandium]]

See build/docs/rust.rst, section "Linking Rust Crates into something else", where something else would be webrtc (which itself ends up in libxul, but that's mostly irrelevant).

Comment 4

[Nathan Froyd [:froydnj]]

I don't think you can have two separate RustLibrary things that feed into the same binary; I think the build system will even yell at you if you try to do that. RustLibrary produces, in Rust parlance, a "staticlib", which contains a copy of the Rust runtime library (what clang calls compiler-rt), and ISTR the linker getting unhappy about duplicate symbols if you attempted to link two such staticlibs into the same binary. And I don't think Cargo gives you any way of producing a (compiled!) Rust library without those runtime bits.

Comment 5

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

See Bug 1620045