1860246 - Permit more than one RustLibrary in mozbuild

Status: RESOLVED WONTFIX

(Firefox Build System :: General, enhancement)

Description

[Ikey Doherty]

Conventionally the build system has enforced that only one RustLibrary() may be linked into the final target, i.e. libxul.so.

However, for our efforts on Thunderbird researching oxidisation within the app and for SDKs, we've learned that removing this build-system limitation will only result in build failure if the downstream isn't correctly adapted.

Our plan is to build a secondary Rust crate (staticlib) that reuses the existing mozilla-central-workspace-hack workspace dependencies, i.e. ensuring identical shared code. This is then linked against libgkrust into the final libxul using muldefs linker strategy.

While we appreciate that muldefs isn't always the right path, it is fair to comment that Firefox + Thunderbird have extensive testing that would immediately expose any issues using this strategy, and the plan is to only apply the flag in comm-central, not mozilla-central.

We need this minor scaffolding change to move forwards, and have a functioning prototype that creates a secondary workspace, satisfying the mozilla-central-workspace-hack, without requiring Cargo.toml changes in mozilla-central. The onus is on us to manage build failures when our toml is not synced, and a python script has been developed to automatically sync our toml with the root toml using a correct fallback strategy across /build and /third_party.

As a final note - we would be incredibly appreciative if this change could go ahead, and our plan is for zero impact on the build of Firefox itself, but enabling Thunderbird (and associated projects) to assist in finding paths towards upstreamable improvements in the oxidisation efforts.

(We have a rust xpcom crate + rust based launcher in testing atm)

I'm pushing a patch for this shortly, and appreciate any feedback on making it better.

Comment 1

[Ikey Doherty]

Attachment: Bug 1860246: Remove restriction on number of RustLibrary() used in linking. r=glandium

Rather than us enforcing up front that linking of multiple rust crates isn't
supported, we'll instead rely on downstreams making it link successfully and
exit with failure if not correctly implemented, thus not impacting the overall
builds of Firefox.

Comment 2

[Ikey Doherty]

Attachment: Bug 1860246: Add initial Rust workspace + unbuilt sample. r=rjl

Add the necessary scaffolding to Thunderbird to support the build
of Rust crates + xpcom components under a dedicated workspace that
follows mozilla-central vendorered dependencies for a sane build
approach.

The included example_xpcom tree can be built to verify the machinery
but exists purely for documentation purposes, and is excluded in all
build configurations.

The new rustbird library is built and merged with gkrust by
allowing duplicate symbol definitions (ie don't error out, and use
the gkrust-defined symbols) into the final libxul, allowing us to
implement our own downstream oxidisation efforts.

Note that this work is dependent on upstream support landing for more
than one RustLibrary within the (derived) tree:

• Bug 1860246

Comment 3

[Phabricator Automation]

Comment on attachment 9359903 [details]
Bug 1860246: Add initial Rust workspace + unbuilt sample. r=rjl

Revision D191698 was moved to bug 1860654. Setting attachment 9359903 [details] to obsolete.

Comment 4

[Mike Hommey [:glandium]]

Per comments in phabricator.