| 18 Dec 2025 |
 rosssmyth | But it would be nice for it to be better integrated with Nixpkgs so that more things work better like clang-tools things | 15:36:36 |
 emily | we can just fix that, though. | 15:37:51 |
| emily | I mean, "just" | 15:37:55 |
| emily | it's effort better spent than trying to integrate gcc-arm-embedded further, IMO | 15:38:07 |
| emily | source-building the right GCC is not really the hard part | 15:38:17 |
| rosssmyth | I put some effort into that once and it will probably require a breaking change in the embedded parts of lib.systems or multilib support. For example when one writes lib.systems.examples.arm-embedded that will compile a GCC that only targets Armv4 (iirc). So ror any reasonable usage multilib is required because FUCK compiling GCC for every little arm variant. But if you try to make a GCC for specific targets, it also fails (I can't remember why, it's been a while since I tried). There's also build system funniness, such as CMake interpreting embedded target triple differently than GCC and Clang. | 15:45:35 |
| rosssmyth | * I put some effort into that once and it will probably require a breaking change in the embedded parts of lib.systems or multilib support. For example when one writes lib.systems.examples.arm-embedded that will compile a GCC that only targets Armv4 (iirc). So for any reasonable usage multilib is required because FUCK compiling GCC for every little arm variant. But if you try to make a GCC for specific targets, it also fails (I can't remember why, it's been a while since I tried). There's also build system funniness, such as CMake interpreting embedded target triple differently than GCC and Clang. | 15:45:50 |
| emily | the embedded parts of lib.systems are sufficiently little used that I'm not very concerned about breaking changes to them | 15:46:05 |
| rosssmyth | * I put some effort into that once and it will probably require a breaking change in the embedded parts of lib.systems or multilib support. For example when one writes lib.systems.examples.arm-embedded that will compile a GCC that only targets Armv4 (iirc). So for any reasonable usage multilib is required because FUCK compiling GCC for every little arm variant. But if you try to make a GCC for specific targets, it also fails (I can't remember why, it's been a while since I tried). There's also build system funniness, such as CMake interpreting embedded target triples differently than GCC and Clang. | 15:46:07 |
| emily | (I also don't think one GCC build per target is that bad though) | 15:46:18 |
| emily | (if you don't want to rebuild a compiler per target my suggestion is to use LLVM :) ) | 15:46:26 |
| rosssmyth | I would like to use llvm at work but that has its own challenges that I have not been able to solve yet. Mainly around libgcc and linker scripts. | 15:47:12 |
| rosssmyth | and asm | 15:48:07 |
| rosssmyth | Because Clang does not support the same asm as gcc, it supports mainly a subset of what gcc does | 15:48:37 |
| emily | do you target so many ARM versions (with so little builder resources) that building some GCCs is untenable? | 15:49:19 |
| emily | that said, multilib support wouldn't be a terrible thing | 15:49:27 |
| emily | it would certainly make K900 very happy, for i686 reasons | 15:49:32 |
| rosssmyth | Mainly just two. | 15:50:13 |
| rosssmyth | Once in a while a third one | 15:50:38 |
| rosssmyth | And the builder resources & cache is just my laptop. Such is life as a software engineer at a hardware company. | 15:51:58 |
| emily | for prod builds too? 🫣 | 15:52:49 |
| rosssmyth | I don't really mind building GCC on my laptop. The real issue is GCC on GHA. | 15:52:56 |
| rosssmyth | Of course. | 15:53:03 |
| rosssmyth | Working at a company as the newest hire in like 20 years has some funny things about using contemporary software engineering practices | 15:53:53 |
| rosssmyth | I am one of two software engineers, and I am the only one who uses version control, the only one who cares even a little bit about being able to build our firmware outside of IDE tooling, ci, and other fun stuff | 15:54:59 |
| emily | can you give a rough estimate of how many countries' national security depend on the integrity of your laptop? or maybe planes' ability to remain aloft or medical devices' proper functioning? :D | 15:55:06 |
| emily | but yeah, big builds on GHA is a pain | 15:55:14 |
| emily | and I assume your company isn't up for paying for the beefier or third-party runners | 15:55:32 |
| rosssmyth | I know we interact with the US military but I'm unsure what we do with them.
We have major contracts with the single company that does almost all testing of silicon wafers for all foundries
We have many contracts with various medical device manufactuers
No aerospace contracts (yet!)
And yeah, we just have the cheapest github plan at like $50/year | 15:56:53 |
| rosssmyth | Also if you drive a Tesla Model X, we have hardware in the rear power seats | 15:57:09 |
