http://bugs.winehq.org/show_bug.cgi?id=22132
--- Comment #8 from Thomas Orgis thomas-forum@orgis.org 2010-03-23 10:03:50 --- I am sorry that you don't see this as improvement. I actually wanted to make things better. Also, I figured that it would be early enough to catch this now, before any stable release of wine using libmpg213 is out.
Last time I checked, wine version 1.0.x does not use libmpg123 yet. So, I actually don't see the big issue with backwards compatibility. Yes, there is the case of someone having a recent build of wine-1.1.x installed breaking it by upgrading mpg123 to 1.11. Then that someone needs to rebuild wine -- I consider that far less severe for a development version than for a stable end-user release. Isn't the development release series there to iron out issues before stable?
Isn't it perhaps a possibility to make wine require a minimum mpg123 version of 1.11.0? That's easily done using pkg-config macros ... then, one only needs to check for libmpg123_64 if large file support is enabled, otherwise libmpg123. Why do you really want to add ugly magic to make wine work with problematic incarnations of the mpg123 library?
I don't say that the separate library approach is the best one, but it is at least one that avoids incompatible libraries under the same name. Sure, it's the least-effort approach. But it is that for a reason: I need my life time for different things. This may be harsh, but I don't have an army of hackers behind be, begging to get some work to do for mpg123:-/ Also, I am trying to avoid code (conversion and overflow checking of exernal/internal off_t) that is specific to a platform (Linux/x86) that I don't use for daily work. I'm on x86-64 since quite some time now (that may be a reason for my earlier blindness on the large/smal file support issue).
I see now that the "right" solution would be to rewrite the API to avoid exposing off_t ... and avoid exchanging file descriptors. I don't have time for that, and I admit that I am really annoyed by this all (not you -- the situation).
I actually discussed with the debian mpg123 maintainer about this and in the end followed his recommendation of an soname change for the large file version. I tried to get input from people about this... nobody actually suggested that what I am doing is A Very Bad Thing. There are other libraries that have a 32 bit and a 64 bit offset variant -- but granted, most either ignore the issue or hide off_t. I fail to see why you really have to invest more work on this from your side than looking for both libs and using the one that matches your large file setup -- what my configure patch does.
The most important thing is to prevent screwing users by broken defaults. Now, when wine uses large file support by default (and possibly requires mpg123>=1.11), it will link with libmpg123_64 and it is clear that it requires a default install of mpg123 which gives you libmpg123_64. I really don't want you to regret using libmpg123. I do regret the mess I caused with the off_t in the API. I now see that you also are not happy with my solution, but it is not exactly impossible to adapt to it (and be safe from future troubles with this -- promised!). Can wine and libmpg123 still be friends?