zlacker

> It's the exception which is why it's talked about the most.

It's definitely not the only exception. libgl is another obvious example since different GPUs need different userland code. I would be surprised if there there had never been compat regressions in those.

>>mikepa+(OP)
libgl can be dlopened, glibc can't be. That is the problem. If libgl has some incompatibility, I can try to work around that. If glibc has some incompatibility, my executable won't even launch.

I agree with this article completely.

>>HexDec+2d
> libgl can be dlopened, glibc can't be. That is the problem.

What exactly prevents this for glibc? I assume you'd need a dlopen equivalent from somewhere for bootstrapping, but are there other issues (like TLS or whatnot)?

>>datafl+7w
Yeah, TLS is one reason. I don't remember the details, but last time I looked into it, glibc abd the loader have some private interface that they use to load the program correctly, and there are no stability guarantees for this interface. Ideally, the loader and libdl will ship with the kernel, and glibc will have to use the public interface they expose.

>>HexDec+wx
If that's the case then it feels like it proves they just don't care enough about compatibility...