http://bugs.winehq.org/show_bug.cgi?id=22132
--- Comment #6 from Thomas Orgis thomas-forum@orgis.org 2010-03-23 04:32:31 --- Ok, so let me explain. First, I am talking about 32 bit Linux/Solaris systems only here. Nothing changes for systems that do not have ambiguous off_t size.
Binary compatibility has been broken at the time I introduced large file support in mpg123 1.5 . Before that, libmpg123.so always exposed an ABI with 32 bit off_t. After the change, the default install switched to 64 bit off_t. In any case, users were able to specify --enable-largefile or --disable-largefile to yield libmpg123.so with different ABI. That is troublesome.
Back then, I was not really aware of the mishap I am causing, also thinking that I am rather late switching on large file support and that the world is supposed to build for large files, at large. That is wrong. Many apps won't bother with this, ever, and not everyone aggrees that one should be able to play mp3s > 2G (actually, the big off_t is also needed to represent byte offsets in the _decoded_ stream).
The recent trouble with wine failing to build with libmpg123 on multilib systems made me more aware of this. And yes, I decided to break a bit of binary compatibility for the sake of ending the current state of latent binary incompatibility with itself.
On a system where you have optional large file support, the large-file-libmpg123 will be called libmpg123_<width_of_off_t>.so (so, currently that's libmpg123_64.so on 32 bit systems). The default size of off_t will be offered by libmpg123.so, as it was the case before mpg123 1.5 and as it is still the case for any install that did not enable large file support (for example to keep backwards binary compatibility!). I hope that distributions will adopt the practice to install both libmpg123.so and libmpg123_64.so to make apps happy.
I have to hurt somebody at this point. I decided to do a cut now to prevent the current situation to extend to the future and really start to hurt users. Wine is about the biggest project starting to use libmpg123 and I think it is a good idea to make sure that it works with least surprise once there is a stable release. I really did that rename for the sake of ABI stability: Once you built wine on a 32 bit box with large file support, it will depend on libmpg123_64.so and my change guarantees that this library will always provide an ABI with 64 bit off_t.
The old way of shape-shifting libmpg123.so would only cause trouble when installing a wine binary on a system where mpg123 was built using different large file setting. Doing that change now could come in time to keep a sane upgrade path on one major Linux distro: stable debian is on mpg123 1.4, pre-largefile. I'd like the next debian release to include 1.11 instead of one of the versions that _will_ break binary compatibility for anything built on stable debian.
Was I able to convince you that this decision is necessary to put an end to the legacy of bad decisions about the mpg123 API/ABI?