Simon McVittie <s...@debian.org> writes: > On Sun, 26 Jan 2025 at 09:14:30 -0800, Russ Allbery wrote:
>> maybe it's more common these days to have plugin libraries that aren't >> linked with libc? Back in the day, it was very rare for people to >> successfully manage to write code that never called a libc symbol. > In ecosystems with a "platform" runtime library like GLib, Qt or even > SDL, and especially when intending to be portable to Windows and macOS > as well as Linux and other Unixy platforms, it's very common to write > code that only ever calls into that runtime library, and never directly > calls libc functions. I think the reason Jeremy is so negative about > this lintian check is that false positives are particularly common in > GNOME, where basically everything is linked to GLib and uses its > functions in preference to going directly to libc. I suspect what's changed since the introduction of this tag is that use of as-needed is now much more common and as-needed is removing the libc dependency. That specific pattern is safe, since the libc dependency would be introduced if it were needed in the future. Unfortunately, Lintian currently can't distinguish between that case and the case where the linker was told not to link against libc at all. In theory it would be possible to do better in Lintian by scanning the symbol table to see if the libc dependency is really unneeded. But doing that sounds at least a little annoying. Downgrading the tag is not really a fix. That doesn't make the false positives go away; it just encourages people to ignore more Lintian tags. If people think the problem the tag was designed to detect is so rare as to warrant downgrading to pedantic, I would just delete the check entirely. I have a warning flag set in the back of my head that it's possible for GCC to introduce calls into libc even if they're not present in the source (memcpy, maybe?) unless you explicitly tell it to build things in standalone mode, although maybe I'm misremembering. It's certainly easy to introduce a libc dependency by writing normal C code and calling some function that's universally available, including on Windows, without thinking about it, thus making the state of "not using libc" somewhat unstable. But problems like that combined with a build system error of omitting libc entirely are probably much less common than as-needed removing libc because it's not needed. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
