Comment by pizlonator

This is a really great article about binary compatibility!

I disagree with their idea for fixing it by splitting up glibc. I think it's a bad idea because it doesn't actually fix the problems that lead to compat breakage, and it's bad because it's harder than it seems.

They cite these compat bugs as part of their reasoning for why glibc should be split up:

- https://sourceware.org/bugzilla/show_bug.cgi?id=29456

- https://sourceware.org/bugzilla/show_bug.cgi?id=32653

- https://sourceware.org/bugzilla/show_bug.cgi?id=32786

I don't see how a single one of these would be fixed by splitting up glibc. If their proposed libdl or libthread were updated and had one of these regressions, it would cause just as much of a bug as if a monolithic libc updates with one of these regressions.

So, splitting up glibc wouldn't fix the issue.

Also, splitting up glibc would be super nasty because of how the threading, loading, and syscall parts of libc are coupled (some syscalls are implemented with deep threading awareness, like the setxid calls, threads need to know about the loader and vice-versa, and other issues).

I think the problem here is how releases are cut. In an ideal world, glibc devs would have caught all three of those bugs before shipping 2.41. Big corpos like Microsoft manage that by having a binary compatibility team that runs All The Apps on every new version of the OS. I'm guessing that glibc doesn't have (as much of) that kind of process.