This is the heart of the problem

but even if you use glibc, the glibc developers can't implement policy in your apps by implementing some new function, they can only do it if they change an existing function.

so while they can break or change something they currently do, they can't take over other functions at a whim

I don't understand. Why do you think that the glibc implementation of strlcpy() would have all that stuff in it? Did someone write that implementation and contribute it and it was rejected? If so then you can just use that yourself. If not, then most likely if strlcpy() _was_ added to glibc it would just be the simple, unoptimized version you would write yourself. The _fact_ is that there's absolutely nothing preventing anyone from using strlcpy() in their program, any time they want. There's no need for glibc to include it. And even if some newer version of glibc DID include it, how many years would it be before you could rely on it being present on your target systems and remove your own implementation?

> Now try to compile the recent Boost library with this. I know because I did - it's not trivial.

We use Boost 1.53. I don't know if you consider that "recent" or what might have broken in Boost since then, but I don't remember having any particular problem when I built it (for third party stuff like this we build it once then use the results). We also use ICU, MPIR, google coredumper, unixODBC, etc.: we also compile all our build tools like this so we don't have to worry about the version of Linux on our build systems, so GCC, gdb, binutils, bison, flex, make, m4, cmake, git, python, etc.

> I can trivially package all other libraries along with my application. ALL of them (well, except maybe some libcrazy that does something perverted with ld).

I never pack system libraries with my software. If I did, then I'd be on the hook for tracking and providing security updates any time _any_ of those libraries has a flaw. That's too much work, and no matter how good we are at it, it's still not as good as using the upstream distro's security updates.

I admit, as I said before, I rely on a relatively modest set of low-level system libraries that are fairly stable: no Qt, GTK, etc. But we're talking about glibc here anyway. Glibc uses weak binding, versioned symbols, etc. to avoid having to change the major soversion which makes it completely painless to support. Libraries like libcrypto, libssl, libcurl, etc. just bump the major soversion and so are a SERIOUS pain in the rear end.

> Let me tell you how I'm developing applications for Windows XP on Win 8.1 (that's 12 years distance in time).

Lord. Windows is by FAR our most difficult port. For a DLL we build that we need to work with older versions of PHP we have to actually install MSVC 2008 and perform a completely different build with that. Not to mention all the effort needed to install software onto every Windows build machine by hand, set obscure system configuration options to deal with crashes on the headless/unattended build systems, etc. etc. And of course there's all the frustration, expense, and annoyance with getting licensing for all of it.

> Wrong. glibc is THE most problematic library in the Linux stack. Bar none.

You're wrong. Simple as that.

This will be my last post on the matter since we obviously cannot make progress here. I'm going back to using my straightforward environment that requires no chroot, su, or sudo, is 100% relocatable wherever you want to install it, can be bundled into a tarball and copied to a different system without extra packages or configuration, and generates the same result, where that result runs on every Linux system from Red Hat EL 5 or newer and does not require any statically-linked libraries and does not ship any system libraries and still works fine, and which I've been using to ship enterprise products to real customers for years.

Joey Hess seems to claim that shipping glibc with your application is also not hard: https://joeyh.name/blog/entry/completely_linux_distributi...

I build GCC et.al. by running configure and make, as per the README. I have a fancy makefile I wrote that does this. I create the sysroots as described in my previous posts: I get the RPMs and use rpm2cpio to unpack them into a directory, then when I compile and link my code I add the --sysroot=<dir> flag pointing to that directory. You might have to go through the sysroot and replace absolute symlinks with relative symlinks; I have a little Perl script that does this but it's easy enough to do by hand. You only need to do it once (or anyway, once every time you change your base operating system).