[FFmpeg-cvslog] r24156 - trunk/configure

[Ramiro Polla]

On Sat, Jul 10, 2010 at 10:58 AM, M?ns Rullg?rd <mans at mansr.com> wrote:
> 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?

Yes. mingw-w64 started as a 'mingw for 64-bit', and it still was when
I added that check. Then it grew to 32-bit support and also windows ce
(and is nowadays much better than mingw32, along with friendlier
developers). Their vendor string is w64, so we get toolchains such as
x86_64-w64-mingw32 and i686-w64-mingw32 (yes, very confusing). The
name is quite confusing now, I hope they clear it up someday.

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

It's not really clear when mingw-w64 left alpha/beta stage, so I don't
mind not supporting old versions (there has only been one release so
far, and like us, they prefer if people use latest SVN). They have the
mingw32 version defines set to that from when they forked the project.
There is a define for mingw-w64 version, but as I said above it's not
that reliable yet.

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

It seems the avisynth check was not necessary (it does work with
w32api < 3.13), so I removed it.

The issue with vfwcap is that mingw32 did not have some necessary
defines prior to w32api 3.12, and we had them as a hack in vfwcap.c
(which have already been removed from our code). On 3.12 they
integrated one patch from me which was utterly broken (my bad). On
3.13 they fixed it. We can remove this version check and check for the
cpp condition (WM_CAP_DRIVER_CONNECT > WM_USER) instead.

It should be possible to do:
check_cpp_condition vfw.h "(WM_CAP_DRIVER_CONNECT > WM_USER)" ||
disable vfwcap_indev
but that doesn't look clean. We could also enable something on that
cpp condition and add it to vfwcap_index_deps. Suggestions?

The mingw runtime issue is a little different. The MS runtime provides
strtod(), but it is not c99-compliant and fails for us. There is a
replacement c99-compliant strtod() on MinGW exported as __strtod(). On
mingw32 >= 3.15 there is a hack that chooses the c99-compliant one by
default, but the mingw32 devs have expressed interest in reverting
that change. Since mingw-w64 was forked before that change, it also
fails on strtod() for us. I've been asking the mingw-w64 developers to
also make this change under some ISOC99 ifdef, but they have not done
it yet.

What we could do is define strtod as __strtod as to always pick the
c99-compliant one. This would make both mingw32 and mingw-w64 work
without version checks.

Apart from the c99-compliant strtod() (and the win64 xmm clobbering
issue), mingw-w64 works for FFmpeg and regression tests pass. MinGW32
currently fails to compile FFmpeg because of issues declaring some c99
functions under -std=c99, which they have closed as invalid in their
bugtracker. If mingw-w64 makes the proper change for us to get a
c99-compliant strtod() and mingw32 fails to fix their other issues, I
suggest we drop mingw32 support and only support mingw-w64 (for 32-
and 64-bit, and possibly also wince if Martin is willing to test it
=).

Ramiro Polla