[FFmpeg-cvslog] r24156 - trunk/configure

[Måns Rullgård]

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