[FFmpeg-cvslog] r24156 - trunk/configure

[Ramiro Polla]

2010/7/10 M?ns Rullg?rd <mans at mansr.com>:
> Ramiro Polla <ramiro.polla at gmail.com> writes:
>> 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.

Patch attached. We should also add a comment so that we don't forget
why the check works that way. Possibly:
# check that WM_CAP_DRIVER_CONNECT is defined to the proper value
# w32api 3.12 had it defined wrong

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

I don't think so either... Two ideas that come to mind are running a
test program (which is obviously not ok because of cross-compilation),
and testing to see if the symbol from msvcrt is used instead of from
another library (libmingwex), which is way too hackish.

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

Adding a "add_cflags strtod=__strtod" to configure works with mingw32
and mingw-w64.

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

A patch was applied to mingw-w64 today for this. It hasn't been
thoroughly tested though and might be reverted if it has any unwanted
side effects.

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

I don't remember there being any other silent issues like this one.
There was an issue with printf not rounding properly, but that seems
to be ok now both in mingw32 and mingw-w64. I'm setting up new
toolchains for FATE and the autobuilds in the next few days, but the
Internet connection I'm at now drops every minute or so making it
extremely hard to work over ssh.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vfwcap_defines.diff
Type: application/octet-stream
Size: 1521 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20100710/b26180e0/attachment.obj>