[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