diff options
author | wm4 <wm4@nowhere> | 2012-08-07 01:09:42 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2012-08-07 01:09:42 +0200 |
commit | 89b7cb0331c191730b725f09ee575971e82de6c2 (patch) | |
tree | 3c58572fdcc8dc0342745c70ddac95e19bb80e63 /configure | |
parent | 76b98e4c32b4d60e4c3740c3bb96753f9812b982 (diff) | |
download | mpv-89b7cb0331c191730b725f09ee575971e82de6c2.tar.bz2 mpv-89b7cb0331c191730b725f09ee575971e82de6c2.tar.xz |
win32: fix compilation on MinGW
The commit 74df1d8e05aa2 (and f752212c62353) replaced the configure
endian check with byte order macros defined by standard headers. It
turns out that MinGW-w64 actually doesn't define these macros in the
sys/types.h system header. (I assumed it does, because a quick test
seemed to work. But that was because gcc -W -Wall doesn't warn against
undefined macros. You need -Wundef for that.) MinGW-w64 has a
sys/params.h header defining these macros, but sys/types.h doesn't
include it, so it's useless without special casing the mplayer code.
Add a hack top configure instead. Define the macros directly, and
assume MinGW-w64 only works on little endian machines.
The other changes are basically random typos and superficial oversights.
Diffstat (limited to 'configure')
-rwxr-xr-x | configure | 4 |
1 files changed, 4 insertions, 0 deletions
@@ -1018,6 +1018,10 @@ if mingw32 ; then _getch=getch2-win.c need_shmem=no extra_cflags="$extra_cflags -D__USE_MINGW_ANSI_STDIO=1" + # Hack for missing BYTE_ORDER declarations in <sys/types.h>. + # (For some reason, they are in <sys/param.h>, but we don't bother switching + # the includes based on whether we're compiling for MinGW.) + extra_cflags="$extra_cflags -DBYTE_ORDER=1234 -DLITTLE_ENDIAN=1234 -DBIG_ENDIAN=4321" fi TMPC="$mplayer_tmpdir/tmp.c" |