[Bug 22132] update configure to work with mpg123 1.11.0

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=22132





--- Comment #8 from Thomas Orgis <thomas-forum at 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?

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.