4 ms·
> Keeping a existing binaries working is the definition of backwards compatibility in an OS. glibc broke that. No, that's simply wrong. No "glibc binary" that
by ajross 4y ago
> Keeping a existing binaries working is the definition of backwards compatibility in an OS. glibc broke that.
No, that's simply wrong. No "glibc binary" that could have been even theoretically compiled within the past few decades will fail to run because of this issue.
What happened is that this EAC product had reverse-engineered the internal formats glibc uses to provide the APIs it implements. And that format changed.
I repeat what I said elsewhere: it is simply not possible for any software product to anticipate all possible external users of its internal implementation details. What you want, you cannot have. (And I repeat what I said elsewhere too: you don't have this, even on windows. Microsoft breaks things like anti-cheat hackery with every release too, it's just that you don't notice because the proprietary vendors care enough to fix it, where they don't on Linux.)
- brigade 4y ago> No "glibc binary" that could have been even theoretically compiled within the past few decades will fail to run because of this issue. That's obviously not true. The entire story is how a new glibc binary broke existing binaries. > What happened is that this EAC product had reverse-engineered the internal formats glibc Okay I missed this; I thought EAC was parsing the libc binary as per ELF. What was reverse engineered? > it is simply not possible for any software product to anticipate all possible external users of its internal implementation details Correct. Which is why I never asked for stuff that never breaks. What is important is that when stuff is found to break, the breakage and refusal to provide backwards compatibility has a compelling reason. glibc's justifications here are laughable; they're spending more effort to not revert the breakage than it would take to fix. Which is kinda why the story blew up.
- dark-star 4y ago> What happened is that this EAC product had reverse-engineered the internal formats glibc uses No, you got it the wrong way around. EAC has used the well-documented and SysV-standard DT_HASH mechanism. The DT_GNU_HASH is the (almost) undocumented one that they would have to reverse-engineer from GNU ld's source code