4 ms·

Right, I understand that, but this just gets back to my question of "what qualifies as an incompatible version?". Clearly 1.1.X and 1.2.0 are compatible in the

by DSMan195276 5y ago

Right, I understand that, but this just gets back to my question of "what qualifies as an incompatible version?". Clearly 1.1.X and 1.2.0 are compatible in the sense that they still expose the same ABI for 32-bit time_t, and thus programs compiled against 1.1.X will still work with 1.2.0. But as the musl devs identified time_t is commonly used in lots of other places besides libc, so in practice this change requires recompiling all code against 1.2.0 to ensure it is using the right size of time_t, else you might have have programs attempt to communicate with each-other using different sizes. My question is then is this an "incompatible" release or not? From the version number alone I would have assumed 1.2.0 doesn't require a full recompile of everything, but the commenter I responded to suggested it is 'incompatible' and I don't understand why that is the case with feature releases. Do you need to recompile the world for every musl update and ensure everything is compiled against exactly the same version? Or just the feature version has to match?

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 ago
  Right, 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.

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 ago
Right, 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.