[FFmpeg-cvslog] r24156 - trunk/configure

[Måns Rullgård]

Ramiro Polla <ramiro.polla at gmail.com> writes:

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

Thanks for the explanation.

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

Thanks.

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

I'd go with an intermediate property and _deps as you suggest.  I'll
leave picking a name to you as I don't really know what we're checking
for here.  The name should probably contain vfw though.

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

Is there any compilation test we can do to detect this?  I suspect not...

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

That might be trickier than it seems.  Defining that before including
stdlib.h would probably cause some kind of name clash.

To me this is a clear case of broken OS which should be fixed at the
source or patched outside of individual apps.  Surely ffmpeg isn't the
only user of strtod().  That said, I know windows users are hesitant
to patch their systems, so a minimally intrusive workaround here could
be acceptable, at least until upstream is fixed.

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

Sounds reasonable to me.  There's no need to support more than one
native windows environment, especially not when one of them is
somewhat hostile.

Is strtod() the only problem we don't already have explicit checks or
workarounds for?

-- 
M?ns Rullg?rd
mans at mansr.com