2 ms·
The tricky thing with library versioning that you get into is when types change. Let's say my app uses libc and libfoo, both from the underlying operating syst
by mlyle 5y ago
The tricky thing with library versioning that you get into is when types change.
Let's say my app uses libc and libfoo, both from the underlying operating system / distribution.
libc has a 32 bit time_t, and libfoo on my system also has a 32 bit time_t. I upgrade to a new operating system where both libc and libfoo have 64 bit time_t. libc was kind enough to include symbol versioning which makes time(NULL) return a 32 bit number to my binary.
Now, libfoo either has to be patched to handle symbol versioning and have a new version inside so that my app can get the old 32 bit time_t, or it will have a subtly broken ABI.
The thing is-- who does this? Libfoo doesn't know when each distro will make the change: it won't correspond to a specific upstream version. Does each distro have to recognize the issue and introduce symbol versions? Etc.
- DSMan195276 5y agoRight, I get that point, I'm simply asking why musl introduced this change in 1.2.0 - why wasn't this 2.0.0? The fact that the 1.1.0 and 1.2.0 types are incompatible in a significant way seems counter-intuitive to me, and even after looking into it I don't see much in the way of describing how you're supposed to handle musl upgrades. Is the expectation that you recompile everything for every new feature release of musl? I couldn't find that spelled out anywhere but it seems like that is the case, or else stuff will be broken via changes like this one.