[FFmpeg-cvslog] r24156 - trunk/configure

[Reimar Döffinger]

On Sat, Jul 10, 2010 at 02:16:59PM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> 
> > On Sat, Jul 10, 2010 at 12:15:50PM +0100, M?ns Rullg?rd wrote:
> >> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> >> > WTF? This has not the slightest bit to do with this change.
> >> 
> >> The change replaced a check for x86_64 with a different check.
> >
> > Yes, and the x86_64 check was a pathetic way to detect MinGW64
> 
> Why is that pathetic?  I thought mingw64 was by definition mingw
> running in 64-bit mode.

No, MinGW64 is a (somewhat) separate project with the goal of building
a (cross-)compilation environment that can produce 64 bit Windows
binaries, but it can also produce 32 bit binaries.
And just assuming 32 bit windows == mingw32, 64 bit windows == mingw-w64
and then checking version numbers instead of features (and even that only
for the headers, not the tiny C lib that comes with MinGW) is a bit "pathetic"
compared to the quality of our other checks...

> >> > The change is about avoiding an incorrect
> >> > die "ERROR: MinGW runtime version must be >= 3.15."
> >> > When compiling a 32 bit binary using mingw-w64 headers.
> >> 
> >> When compiling a 32-bit binary, "enabled x86_64" should never be
> >> true.  The change only makes any sense at all if x86_64 is incorrectly
> >> enabled at some point.
> >
> > No, the issue is that it is _correctly_ _disabled_
> >
> >> >> >> > -        if ! enabled x86_64; then
> >> >> >> > +        if ! check_cpp_condition _mingw.h "defined (__MINGW64_VERSION_MAJOR)"; then
> >
> > If x86_64 was _correctly_ _disabled_ then the mingw_32_ version check would
> > run even on mingw-w_64_, and fail.
> 
> OK, now I'm thoroughly confused.  Can you please explain to me 1) what
> those version checks are really for,

IIRC ffmpeg fails to compile/link on older MinGW32 versions because they
lack some things. So in order to be nice to users, we tell them straight
ahead this won't work.

> 2) why they fail on mingw64, and

MinW64 does not or not correctly set __MINGW32_MAJOR_VERSION etc.
I'm not sure, but IIRC they made a bit of a mess by adding everything
FFmpeg needs independently from MinGW32 but possibly not some other things
so they can't really claim to be compatible to any newer MinGW32 versions.

> 3) how the VFW version check relates to all this.

AFAIK the w32api is a somewhat independent part of MinGW headers, and
we need a new enough version for the multimedia stuff.
However I doubt the MinGW64 headers will work for our avisynth and
vfw capture support...

But don't ask me for details, I do not use MinGW-W64 and I only rarely
use regular MinGW and even then I only compile MPlayer and some of my
own projects and not FFmpeg...