1. Sorry for bringing this on 😅
2. The main variance (from what I have experienced) is library availability and versioning. But I guess Conan takes care of that.
3. I think the main problem you could experience is compiler versions being a bit behind.
Conversation
wolf:fred ~: clang --version
OpenBSD clang version 10.0.1
Target: amd64-unknown-openbsd6.9
Thread model: posix
InstalledDir: /usr/bin
I don't know how much effort it would be update clang to 13.0.0 in OpenBSD
1
1
OpenBSD maintains several local patches to its system compilers, but the ports maintainers do a good job at generally keeping them in sync with the base clang changes. As for building newer versions of clang that what OpenBSD ships, that's no bueno.
man.openbsd.org/clang-local
1
2
That being said, an update to clang11 is probably around the corner. But that's not bleeding edge.. in general, that's not what you want from system compilers.
1
2
Unfortunately chromium is only guaranteed to build with a bleeding edge clang... but it might build with older versions. The one it comes with claims it’s clang 12
2
1
1
Because of course chromium ships its own compiler and linker
1
1
3
They frequently update it to newer LLVM revisions and end up fairly closely following along with the development branch because they need bug fixes from there and prefer following along vs. trying to backport ridiculously complex intertwined things.
1
4
Android Open Source Project is similar but the main release cycle for major releases is yearly rather than every 6 weeks. They do often end up updating it as part of the quarterly maintenance releases. For the Linux kernel, they also tend to use a more bleeding edge toolchain.
1
2
You can build with a different toolchain but it's just not a good idea because they had reasons to keep updating past the most recent stable recent.
LLVM development is basically part of AOSP/Chromium/Linux kernel development from their perspective since it's so intertwined.
1
3
Linux distributions tend to build with their own toolchain and use system library versions and as part of that they lose a bunch of important bug fixes. They often don't bother using CFI (Control Flow Integrity) etc. and don't care about making sure it has the same coverage etc.
Part of the issue is that the LLVM release cycle is quite slow for something that doesn't have a real extended support release branch with tons of bug fixes. The bug fixes also just tend to be far more complex and invasive than typical projects. Can involve massive overhauls...
1
2
In a sense there is no real 'stable' release of LLVM and from their perspective some arbitrary revision of the development branch which appears to fully work for the time being is a better choice than a known to be broken in many ways stable release which won't get fixed.
1
1
Show replies