-
Notifications
You must be signed in to change notification settings - Fork 195
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-ozone-wayland 114 - FAILED: yocto_native/obj/skia/skia/SkSLType.o #740
Comments
This looks like #726 -- the build's failing when building some bits on the host using your distro's libstdc++, which is too old for what Chromium needs. We're trying to solve that by working on a dunfell-clang14 branch in meta-clang that would use meta-clang's libc++ rather than the distro's libstdc++, but in the meantime you could try using a more recent Ubuntu release on your host (18.04 is EOL anyway) or using a newer GCC release on 18.04. |
Thanks for the info. I was mistakenly using the default crops/poky docker container which still defaults to 18.04. But I still can't build Chromium 114. It ran significantly longer before failing and then spent hours spitting out clang warnings until I aborted it after 8 hours, I couldn't find the actual error though. I see your other thread about creating a clang14 branch so I will keep on eye on that progress too. |
The lots of warnings are unfortunately expected, and will remain until we can use clang >= 15. I'd be happy to help with fixing the build error, but I would need the error message for that 😅 do you still have the temp files of your build? They should contain the logs of Chromium's compile step, and you could look for the error message there. Here are some more detailed instructions: |
Took all day for the build to run. I'm not sure if it really exited properly in the end. The log file was over 6GB. But I did manage to pull the below snippet using your method of searching.
|
Here we go, ran it again, got a faster result. And a better looking error.
|
Not sure why that might happen... my only idea would be to inspect the object files and see what's defined/exported and compare that to what's being referenced. Although I haven't figured out how to do so on my machine yet, because apparently the .o files that make up Alternatively, I think you might have success using the already mentioned dunfell-clang14 branch ( Footnotes
|
Uninformed guess here: every now and then people file issues related to undefined GL symbols, and IIRC most of the time they seem related to imx and different GL implementations. I wonder if that's the case here? |
Could be. I'm building for an imx8 device. I'll give dunfell-clang14 a try and see. Not sure I would be willing to proceed with that in a production setting. |
We're going to stick with the tried and true version 90 until we either change hardware or migrate our BSP to a newer version of Yocto (currently on dunfell). We've actually been testing version 83 with better results for hardware acceleration. I'm wondering if this just might be the boat we're stuck in due to our custom hardware. I'll close this issue. |
Just recently attempted to upgrade from chromium v90 to latest in master and am getting the below compilation error. Figured I'd start here and move the issue to meta-clang if needed. I'm pretty sure I had a newer version building earlier this year so I may step backwards a few versions of chromium and see what results I get.
I set preferred version of nodejs/nodejs-native to 14.% and and am using dunfell-clang12 branch of meta-clang.
I have no modifications to the chromium-ozone-wayland recipe other than
DEPENDS += "at-spi2-atk"
in a bbappend.The text was updated successfully, but these errors were encountered: