-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chromium-x11 build error with Rust enabled #792
Comments
Hm, this should be avoided by this part of our changes to the Rust recipe. Can you please run |
Sorry for the belated response. Here's what you asked for:
|
Hm, I think I know what the problem might be. Are you building for x64 on an x64 machine, i.e. not cross-compiling? |
Correct. But it should still be cross-compiling. |
How is it cross-compiling when host and target architecture are the same? In any case, can you please check if applying the following diff fixes the error: diff --git a/meta-chromium/recipes-browser/chromium/rust_%.bbappend b/meta-chromium/recipes-browser/chromium/rust_%.bbappend
index d103e69..1e139f3 100644
--- a/meta-chromium/recipes-browser/chromium/rust_%.bbappend
+++ b/meta-chromium/recipes-browser/chromium/rust_%.bbappend
@@ -16,6 +16,12 @@ rust_do_install:class-target:append() {
tar -C _dist -xf build/dist/rust-std-${PV}-${RUST_TARGET_SYS}.tar.xz $rlib_path
target_dir=${D}${libdir}/rustlib
+
+ # If we're not cross-compiling, target_dir might already be populated, but
+ # not with the contents we want. See
+ # https://github.com/OSSystems/meta-browser/issues/792.
+ rm -rf $target_dir
+
install -d $target_dir
cp -r _dist/$rlib_path/${RUST_TARGET_SYS} $target_dir
rm -rf _dist |
Cross-compiling in Yocto is not just about a different CPU architecture, it's also about targetting a different OS altogether, that uses a different GLIBC version.
I will test it, thanks. |
It didn't help under mickledore. The same error occurred. I am trying under nanbield now. |
Did you do a full, clean build? I noticed when working on the patch to enable Rust that changes to the .bbappend file don't always get picked up and applied. |
I will try a clean build then. |
It didn't help. I tried this:
Same error. |
Does |
FWIW, I have run The directory contents are not the same. Also, for some reason, there is no Here's the directory contents for mickledore:
and for nanbield:
The error is still the same for
Now, there is There (only quoting for nanbield now), the directory contents are:
EDIT: All of the above was done with the proposed patch added manually:
|
@MaxIhlenfeldt , I am getting build issue for internal master branch (branch having the latest meta-browser master branch all the commits), sharing the build log for reference ERROR: chromium-x11-121.0.6167.184-r0 do_copy_target_rustlibs: ExecutionError('lincd_chromium_121/tmp-glibc/work/core2-64-wrs-linux/chromium-x11/121.0.6167.184/temp/run.do_copy_target_rustlibs.710741', 1, None, None) sharing the recipe-sysroot-native/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/ contents too, could you please suggest how to resolve the issue |
Could both of you please upload the output of |
Pastebin limit is 512KB, the |
Thanks! That's helpful, but I'm still not fully sure what's going on. Could you please also attach the output of |
Here they are. |
chromium-x11.txt |
Thank you both! I'm still not really sure what the problem is. Do you maybe have a |
Not sure if this influences anything, but I also have this bbappend:
|
FWIW, the same issue occurs with Yocto 5.0 Scarthgap for us. I can't share the whole set of layers from our manifest, as some of them are internal layers. In our internal layers, there is no bbappend against llvm, clang, rust or rust-llvm. Here's the public part of
Some of these layers are not officially scarthgap compatible yet. For them, the layer compatibility setting in |
Thanks, I've kicked off a build that should be as close as possible as yours. Let's see whether I'll now get the error as well 🤞 fyi, I'll be ooo for the rest of the week, but I'll get back to this next week. |
Hm, I get this error:
Any idea what the difference between your setup and mine could be that leads to this, @zboszor? |
It's documented in
|
Ok, I've finally been able to reproduce it. I suspect that due to the
Chromium gets a new (transitive) dependency on i.e. our approach breaks as soon as we have anything inheriting the I think we might be able to drop our custom I'll give the approach outlined above a try and will report back here. |
hi @MaxIhlenfeldt , above changes will fix my issue? |
@rjanani-p I'm still working on the fix, the |
@MaxIhlenfeldt , regarding I am getting above issue for 122.0.6261.128 version also for qemux86-64, intel-x86-64, qemuarm64 machines. |
Sorry for the delay, but I think I've finally come up with a patch that should fix this issue. Can you please apply the following patch to Note: please make sure the patch from #792 (comment) is not applied, I don't think it's actually needed.
|
PR for the master fix is up already at #808. |
Thank you very much, I will try your patch soon. |
I have tried it under mickledore first (after re-enabling mickledore support in meta-browser master). An unrelated build error occurred:
Since meta-browser master does not officially support mickledore, I will skip this and test it on nanbield and scarthgap. |
Yes, we had to drop support for mickledore as its version of clang was too old. It should work on both nanbield and scarthgap. |
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>
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>
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>
@MaxIhlenfeldt ,regarding with below change my issue got resolved ,
** |
@rjanani-p thanks for pointing that out. I'll fix it in a separate PR as we should also use the |
@MaxIhlenfeldt I will have the test result for nanbield in about 2-3 hours. Please wait until my build finishes and if possible, merge #809 before #806 so our nanbield builds can get chromium 122. Thanks in advance. |
@MaxIhlenfeldt My chromium build passed the point where the above quoted errors occurred. With a bit of luck, it finishes. FWIW, my Yocto setup does not use |
@MaxIhlenfeldt |
@MaxIhlenfeldt The scarthgap build failed with:
|
sure @MaxIhlenfeldt , thank you |
As usual, we'll create a |
Hm, I didn't touch anything related to the clang setup... maybe it's related to the same issue @rjanani-p reported. Can you please try if the error still happens if you also apply the changes from #810? If the error persists, please paste the output of |
#810 fails the same way. Here's is the info you asked for:
and
|
Thanks. I'm pretty sure this is #794. |
Thanks, I'll try, with cleaning up |
The scarthgap build has passed the point of the previously quoted errors, it will succeed. It's almost at 20% now. |
And indeed, it finished succesfully. #809 can be merged as far as I am concerned. |
I will run the build both for nanbield and scarthgap during the weekend with the changes. |
With the new contents of #809 , the scarthgap build finished successfully. On to nanbield. |
The nanbield build also succeeded. |
chromium: Depend on libstd-rs instead of rust 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. Also, while we're already reworking our Rust setup, we can remove the remaining part of our bbappend for the rust recipe and instead inherit the `rust-common` class, thereby inheriting `rust-target-config` (which needs stuff from `rust-common`). This means we get the `target.json` files the Rust compiler needs installed in the directory pointed to by the `RUST_TARGET_PATH` environment variable. 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>
Thanks for testing! |
Original: https://lists.openembedded.org/g/openembedded-devel/message/109009
Hi,
since commit 0438fba
("chromium: Enable Rust") in meta-browser, I get this error
on several different chromium-x11 builds (i.e. Fedora 33 and
Fedora 39 hosts, mickledore and nanbield Yocto versions):
Obviously, using the previous commit works.
Best regards,
Zoltán Böszörményi
The text was updated successfully, but these errors were encountered: