[MPlayer-dev-eng] swab is in string.h on win32 and declaration conflicts

[Diego Biurrun]

On Mon, May 23, 2011 at 03:05:20PM +0300, Ivan Kalvachev wrote:
> On 5/22/11, Diego Biurrun <diego at biurrun.de> wrote:
> > On Sat, May 21, 2011 at 01:25:05AM +0200, Gianluigi Tiesi wrote:
> >> On Sat, May 21, 2011 at 12:36:37AM +0300, Ivan Kalvachev wrote:
> >> > On 5/18/11, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> >> > > Gianluigi Tiesi <mplayer <at> netfarm.it> writes:
> >> > >
> >> > >> on mingw32 swab is defined is string.h thus not detected by configure
> ----------------^^
> 
> >> > >> that looks in unistd.h
> >> > >
> >> > > http://thread.gmane.org/gmane.comp.video.mplayer.cvs/17298
> >> >
> >> > Will you revert this revert or do you prefer I to be the one to do it?
> >> >
> >> > This check seems too harmless to be removed so soon after
> >> > "fixing" the need for it.
> >>
> >> what's the rpoblem by including both headers?
> >
> > I had upstream fix this issue, update your MinGW64.
> 
> I suspect that mingw32 is separate from mingw64, so the bug there has
> been left unfixed.
> 
> Also fixing something upstream is not valid reason to cripple
> ourselves by dropping the proper checks.
> New build/versions of compilers always have some (new) problems to
> iron out, especially the mingw. Been able to use older version is more
> than desired feature for a package builder.
> 
> The point is.
> Having the check in configure doesn't cost us anything, so we have no
> gain from removing it. However it is huge pain for the users when they
> have to hack around mplayer to build it.

You are wrong, the costs do add up.  Small as they may look at each
incremental step, you end up with 10k lines of configure to support
all system-specific shenanigans.

What is worse, however, is that every workaround that is added by users
of the platform makes it less likely that the platform itself actually
gets fixed.  We have witnessed this for years with the BSDs, porters
kept adding gazillions of workarounds to each application instead of
fixing their libc once.

Plus, it is *easy* to get MinGW fixed, as I have already proved.  There
is absolutely no excuse to waste more time flaming here than it would
take to get MinGW fixed.

Diego