Hello everyone, (TL;DR at the end)
I've mostly been lurking on Debian mailing lists for a long time, so if you don't know me, I'm John, a Debian Maintainer working on a couple cross toolchains for building the device firmware that *is* free from source, but I pitch in on many packages here and there and wear different hats. I still have a lot to learn, but I'm working my way down the stack to learn more and to advance free software as well as hardware that can facilitate it. I don't represent Debian in this capacity, but in particular I'm a member of The Austin Group (https://www.opengroup.org/austin/), the body that maintains the POSIX and Single UNIX Specification standards—although I'm mostly an observer there and likewise do not speak for them. I think a few other Debian contributors are members as well; a full list is at https://pubs.opengroup.org/onlinepubs/9799919799/frontmatter/participants.html In mid-2024, The Open Group and the IEEE (and hopefully the ISO/IEC standards bodies soon as well) published POSIX Issue 8 and the Single UNIX Specification 5 (SUSv5). The reason I'm sharing that is because POSIX specifies how a C compiler can be invoked on a conforming system so that essential functionality can work across different UNIX-like systems without needless change. A big part of the 2024 major revision, the first in about fifteen years, was incorporating C11/C17, the version of the ISO C standard that introduced atomics. In this revision of POSIX, the standardized C compiler is installed under the name 'c17'. Neither Debian nor GCC make any claims to adhere to this part of the standard and there have always been minor quirky differences between GCC's command-line syntax parsing and how the standard says it should be done for the standardized compiler (formerly named 'c99'), but in practice I believe GCC and GNU software generally tries to adhere when it makes sense and entertains patches to improve compatibility with other systems and standards when they're wholesome. POSIX says that systems may require specific compiler flags to access particular sets of functions. For example, use of the "-l m" option may be required for the math functions to be available when building an application. At https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358#c16 you can see the bug report to GCC upstream asking for GCC to link with the atomics support library when necessary as required. Atomics require special care mainly from the compiler and its machine code underpinnings (as opposed to the ISO C standard library), so GCC is the main orchestrator of atomics and is best informed to handle this. In my reply to that bug, I shared an insight I had which is that, in my personal opinion in trying to interpret the specification, a compiler conforming to POSIX may *not* require the usage of special compiler flags to get support for atomics, except if those systems pre-define the __STDC_NO_ATOMICS__ macro to indicate the absence of any claim by the OS to support atomics. In particular POSIX does not specify an "-l atomic" option, but it does say that the compiler, by default, will expose all of the symbols needed for functions and objects specified in headers like <stdatomic.h>, except for those special exceptions like "-l m" for math and "-l rt" for realtime functionality. No such exception was added for atomics-related symbols. GNU is not afraid to deviate from specifications if doing so better serves users (https://www.gnu.org/prep/standards/html_node/Non_002dGNU-Standards.html), but they ultimately do whatever is most useful, especially when they coincide. This quirk of how to link with support for atomics mostly shows up on less common architectures and I figured maybe this hasn't been on GCC's radar because of that, and folks building software for such systems are probably more likely to figure out how to appease the compiler on-the-fly. Therefore, in my appeal on the upstream bug, I shared that addressing this issue in practice will have the bonus feature of helping standards conformance and interoperability with other systems as well (this being more of an "issue in principle"). I was delighted when I saw in my inbox some time later an update that a fix had been made upstream. It apparently caused regressions on some systems so it had to be promptly reverted, but this is to say that problem-solving efforts have been making great strides very recently. For Debian's needs, as-needed linking with libatomic could maybe be done without as much fuss downstream in the meantime, but I don't really work on Debian's core GCC packages and can't judge how easy this could be. This silly technicality is not something that upstream applications should have to care about, or even really build systems. GCC is the right place to fix this and they're fortunately doing it right now. Other downstream hacks we might could do is have dpkg or debhelper set build flags appropriately, again mainly just for the short-term. TL;DR Building programs using atomic types being so hard in corner-case situations is tragic, but to bark up the wrong tree by asking application maintainers (upstream or downstream) to mitigate this would be an awful way to double-down on the error and make more enemies than friends. To ask upstreams to add hacks for the benefit of esoteric systems they probably don't have handy is not something I would be able to do in good faith. A motivator for me to flee from proprietary software was realizing that the developer-user relationship there was not an exchange for mutual benefit, but one that would put arbitrary and contrived barriers in my way and take time away from my life to work around an issue that's plagued millions before me already. I feel so strongly about this because it's shaping up to be an example of how Debian's attiude towards quality assurance and scrutiny of systemic hurdles often delivers large long-term benefits and I take pride in it. Let's help everyone make informed decisions and do what they need to do, and this should ideally be left to the toolchain folks. Adding information to a "GCC known issues" page to help particular developers find a quick fix would be pretty nice though. Thanks for your attention, John
signature.asc
Description: This is a digitally signed message part
