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

Reimar Döffinger Reimar.Doeffinger at gmx.de
Thu May 26 21:10:41 CEST 2011


On Wed, May 25, 2011 at 05:34:24AM +0200, Gianluigi Tiesi wrote:
> On Tue, May 24, 2011 at 11:04:53AM +0200, Diego Biurrun wrote:
> > 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.
> > 
> 
> it's really not a big deal for me to fix my headers, but this will break
> compilation on standard mingw installs too (http://www.mingw.org/)
> 
> I'm not sure mingw64 (that also ships 32bit compiler) will replace www.mingw.org
> Perhaps cygwin toolchain for it's still broken, it links advapi32 symbols to kernel32
> and at least on winxp x64 and 2003 x64 registry handling functions are still in advapi32

I managed to compile MPlayer on cygwin with the mingw64 toolchain,
except that I had to add back the check for swab in stdlib.h.
Would I get strong objections if I added it back with a comment
saying to remove it once Cygwin has updated its copy to a fixed
upstream version?
I'd really like to keep Windows builds hassle-free and at least
in case of MinGW64 it is just a matter of waiting for a "distribution"
update.


More information about the MPlayer-dev-eng mailing list