3 ms·
> It doesn't really excuse the abrupt removal of the compatible hash table format without at least a deprecation effort ahead of time. I strongly suspect that
by cesarb 4y ago
> It doesn't really excuse the abrupt removal of the compatible hash table format without at least a deprecation effort ahead of time.
I strongly suspect that the reason for the "abrupt" removal was that it wasn't expected that anything would break: that table is used for dynamic linking, and the dynamic linker comes with glibc itself, so it can be assumed to understand the new table (and the dynamic linker which comes with other C libraries would be used to load these C libraries, and not glibc since you cannot load more than one C library in a single process). AFAIK, the code in the dynamic linker which understands files with only the old table wasn't removed, so from that point of view, compatibility was being kept.
That is, they didn't expect anything to be using that table without going through dlopen() and dlsym().
- cratermoon 4y agoPublic vs. Published. https://martinfowler.com/ieeeSoftware/published.pdf https://martinfowler.com/ieeeSoftware/published.pdf
- fweimer 4y agoExactly. In addition to that, it seemed very likely that the glibc 2.34 reorganization already broke software which depended on such hidden implementation details.
- dzaima 4y agoIf that were the case, the plan should've been to revert if things do break, i.e. revert an improper action when you find it's based on false premises. But that's not what we see here.
- a1369209993 4y ago> since you cannot load more than one C library in a single process You actually can, and there are even some benighted corner cases where you need to (eg, providing a fake glibc to a DRM/anticheat system or other such malware while your plugins use a different one). It's not properly supported and making it work is !!fun!! in the Dwarf Fortress sense.