chromium: Depend on libstd-rs instead of rust #809
Conversation
Fixes OSSystems#792. Build and patch changes: ------------------------ In OSSystems#782, we decided to depend on rust instead of libstd-rs, because the latter didn't include libprofiler_builtins and also used a naming scheme that trips up Chromium. However, in OSSystems#791 we decided to patch Chromium so that it doesn't need libprofiler_builtins any more, because the master version of the rust recipe also doesn't include it. Finally, while investigating OSSystems#792 it turned out that our approach breaks as soon as we have something that depends on libstd-rs in our dependency graph. In that scenario, both libstd-rs and rust (the latter due to our bbappend file) install Rust libraries to /usr/lib/rustlib. This first leads to Chromium build system errors (due to libstd-rs's naming scheme), and after fixing these to Rust compiler errors due to multiple versions being present. The conclusion is now that we can depend on libstd-rs we should do so. This only requires a small change to Chromium's Rust build scripts to adapt them to the slightly different naming scheme. License changes: ---------------- Added licenses: none. Removed licenses: none. Updated licenses: none. Test-built: ----------- * chromium-wayland: - nanbield, clang, MACHINE=qemuarm64 * chromium-x11: - master, clang, MACHINE=qemuarm Signed-off-by: Max Ihlenfeldt <max@igalia.com>
| @@ -0,0 +1,9 @@ | |||
| FILES:${PN} += "${libdir}/rustlib/*/target.json" | |||
There was a problem hiding this comment.
this bbappend seems a bit off place to me. It should be submitted to oe-core and discussed there so it can be included there. Since Standard rust library should be built once and correctly. There is more than chromium who use rust in OE and it will impact all those packages silently when meta-chromium is included.
There was a problem hiding this comment.
If that happens, it should be backported to nanbield before it reaches EOL. Otherwise we are stuck with chromium 120, at commit ea731e8
There was a problem hiding this comment.
I agree that we should try to upstream the changes from both of our bbappends, now that the rust bbappend is also just about installing the target JSON.
There was a problem hiding this comment.
I got curious why e.g. librsvg didn't run into issues with this and took a look at the recipe. I think we might be able to concoct something using the rust-target-config class, I've started experimenting with it.
There was a problem hiding this comment.
Just pushed a commit that drops all our bbappends and instead inherits the rust-common class (just inheriting rust-target-config doesn't work, it needs stuff from rust-common).
…onfig / rust-common
Fixes #792.
Build and patch changes:
In #782, we decided to depend on rust instead of libstd-rs, because the latter didn't include libprofiler_builtins and also used a naming scheme that trips up Chromium.
However, in #791 we decided to patch Chromium so that it doesn't need libprofiler_builtins any more, because the master version of the rust recipe also doesn't include it.
Finally, while investigating #792 it turned out that our approach breaks as soon as we have something that depends on libstd-rs in our dependency graph. In that scenario, both libstd-rs and rust (the latter due to our bbappend file) install Rust libraries to /usr/lib/rustlib. This first leads to Chromium build system errors (due to libstd-rs's naming scheme), and after fixing these to Rust compiler errors due to multiple versions being present.
The conclusion is now that we can depend on libstd-rs we should do so. This only requires a small change to Chromium's Rust build scripts to adapt them to the slightly different naming scheme.
License changes:
Added licenses: none.
Removed licenses: none.
Updated licenses: none.
Test-built: