Fix build on modern Linux distros (GCC 15, glibc 2.43)#234
Fix build on modern Linux distros (GCC 15, glibc 2.43)#234KonTy wants to merge 2 commits intoAsteroidOS:2.0from
Conversation
|
Thank you KonTy! I feel that the right place for the mesa, virglrenderer and dtc fixes would be upstream yocto repositories. Did you send the fixes here because you think they wouldn't accept those on the walnascar branch we use ? Do you have any clue whether they could they take those changes on the whinlatter branches ? Curiously enough, we don't have much experience contributing this kind of build fixes to upstream Yocto so I'm not too familiar with the process. If these fixes can't be contributed to the Yocto branches we use, then we could take the bbappend in meta-asteroid but I fear this is onboarding a bit of tech debt for us. Re nfcd, the base recipe is being upgraded by #209. Since this is a super massive change and its author has been working on it for a long time and it is seemingly approaching its final state, I don't want to throw more rebase burden on its author. If that's ok with you, we'll first work on getting that nemomobile update PR in before getting back to the PR here. Also, the right place to fix this would be https://github.com/sailfishos/nfcd. I expect they would be open to a PR for your patch and this would also keep our maintenance burden more sustainable. |
|
@FlorentRevest honestly I'm just learning the codebase, and I'm trying ti figure out what's what, let me see if I can figure out those dependencies. Sorry about that. I just got the watch earlier and very excited about your project. I want to help out, I'm a developer of Microcore (still private since it is not done yet but I can make you contributes so you can help me test and give me feature requests :) ) which is a fitness app, completely open source and local no cloud needed you own your data. So I want to try to integrate the app and the watch, I think it would be so cool Please bear with me, don't kick me too hard, I'm just learning my way around. I need your help to understand the system, and I want to become a contributor eventually. |
|
From a quick look at least the dtc fix seems to be available upstream: openembedded/openembedded-core@28552a7 |
|
I've actually been on Fedora 43 for a while now and have been using gcc15 since Fedora 42, and AsteroidOS compiles for me without error. I'm curious about what the difference is. For the first check, I looked at the source code of Does that match yours? |
|
Thank you guys for your great advise I will look at it later today when I have time |
glibc 2.43 exposes once_flag and call_once from <stdlib.h>, which conflicts with mesa's bundled C11 threads emulation. Enable the system <threads.h> on all platforms that provide it, not just Android. Also switch the EGL sync code from mixed C11/POSIX types to pure POSIX types, since cnd_t and pthread_cond_t are distinct in glibc.
Same once_flag conflict as mesa. Detect system thrd_create and use the system <threads.h> when available, skipping the bundled emulation. Also adds explicit pthread.h include to u_thread.h which previously got it transitively through the bundled threads_posix.h.
KonTy
force-pushed
the
fix/build-with-modern-toolchains
branch
from
ffd91c7 to
f81e146
Compare
|
I've updated this PR to drop the `dtc` and `nfcd` workarounds as requested.
Regarding `virglrenderer` and `mesa` glibc 2.43 C11 threading issues:
Since these patches aren't yet available on the OpenEmbedded base layers Asteroid uses, shall I keep them here temporarily, or do you prefer I submit them to `openembedded-core` `walnascar` branch and wait for the Yocto backports to merge before fixing AsteroidOS? |
|
Great job on this, thanks! Since |
|
I bought TicWatch 3 ultra but I need to make a usb cable for it, so I'm working in a QEMU right now. My ultimate goal for hte first 2 weeks is to add a Power Manager where you can add Power profiles. Like in garmin where you can have profiles where you specify when sensors and radios are on and intervals for them. Comming from Enduro 3 I really want us to last for as long as we can squeeze from it. I was reading about 4100+ and thier RTOS processor. sucks we can't inject our own OS into it. it would be awesome to write our own RTOS. Are you ok if I fix QEMU images? right now everything is broken I can't click on things, I can't do swiping 90% of the time. I think it would help me speed up UI development if I can just boot an image on my machine. PS do you have a usb cable for ticwatch that you can sell? I'm trying to make one following github post here as you I wrote this health app and was looking for a first class citizen watch to pair it up with. But all the watches these days are encrypted and very closed source. Your OS is AWESOME and perfect. Please do not even stop working on it. We need more open source in this world. I would like to help you turn this watch into health research platform with sleep phase detection. I have some experience in that area where we can use some oxford AI models that are better then mainstream watches (garmin fitbit) to detect sleep phases. I would like to add workouts where you can chose data screen and power profiles, so you can determine which sensors are on for which workout. **Let me know what your highest priorities are at this point can I help you get through these like tools, libs, compilers incompatibilities etc. ** so we can focus working on fun stuff |
|
@beroset @FlorentRevest |
|
Sure :) we're on Matrix https://asteroidos.org/contact/ this is where all discussions happen and would be the right place to get informed about project plans |
4 participants
Title: Fix build on modern Linux distros (GCC 15, glibc 2.43)
Hi,
I have been trying to build AsteroidOS from source for a while now and I kept hitting build failures. It turns out that AsteroidOS does not compile at all on any recent Linux distribution. I am on Arch which ships GCC 15 and glibc 2.43, but anyone on Fedora 42 or even Ubuntu 25.10 will hit the same wall. These are not edge cases, these are the defaults now on most distros people actually use for development.
I spent a good amount of time tracking down what was going wrong and it came down to four separate issues. I fixed all of them and tested everything thoroughly before submitting this.
Here is what was broken:
dtc would not compile because GCC 15 made some warnings into errors. Two variables had wrong const qualifiers. Straightforward fix, works fine on older compilers too. I ran the full dtc test suite after patching it, all 8 test suites passed.
nfcd had a race condition in its build system. When you build with parallel make (which everyone does), the debug and release builds both try to generate code in the same directory at the same time. One process would overwrite a header file while the other was still reading it, so you would get random compile errors about unknown types. I added a dependency so they run one after the other. Simple and reliable.
mesa would not build because glibc 2.43 now defines C11 thread types like once_flag directly in its headers. Mesa has its own bundled copy of those same types and they clash. Mesa actually already had code to handle this but it was only enabled for Android builds for some reason. I removed that restriction so it works on Linux too. I also had to clean up some EGL code that was mixing C11 and POSIX thread types which are now different structs in glibc.
virglrenderer had the exact same glibc conflict as mesa. Same root cause, similar fix. I had to add the detection logic, update the config template so the build system actually passes the flag through, and add a missing include that used to work by accident.
Everything is done through bbappend files so I did not touch any upstream OE recipes. Each fix is in its own commit.
For testing I did a complete asteroid-image build for the emulator target. All 8101 build tasks completed successfully. I also ran the upstream test suites, dtc passed all 8 out of 8 test suites and virglrenderer passed 7 out of 7 tests (the 8th is a hardware GPU test that is expected to time out on a build machine without a real GPU).
I think this is pretty important to get in. Right now if someone follows the build instructions on a modern system they will just get a wall of errors and no working image. That is probably turning people away. These fixes are small and safe and do not change anything for people on older toolchains.
Let me know if you want me to change anything or split this up differently.