[FFmpeg-cvslog] r24156 - trunk/configure

Måns Rullgård mans
Sat Jul 10 15:58:50 CEST 2010

Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:

> 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...

So mingw32 is always 32-bit and mingw-w64 can be either?

>> >> > 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.

Would it be possible to check for these features instead of version numbers?

>> 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.

So all mingw-w64 versions are OK?  Still, checking features instead of
versions would still do the right thing, no?

>> 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...

Then checking those headers only if !mingw-w64 seems wrong.  Once
again, what are the precise features we need?  Is there some reason we
can't check for those instead of looking at version numbers?

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-cvslog mailing list