[FFmpeg-devel] FATE failure on mingw gcc-4.2.4
Ramiro Polla
ramiro.polla
Thu Mar 11 13:51:18 CET 2010
2010/3/11 M?ns Rullg?rd <mans at mansr.com>:
> Ramiro Polla <ramiro.polla at gmail.com> writes:
>> 2010/3/9 M?ns Rullg?rd <mans at mansr.com>:
>>> Ramiro Polla <ramiro.polla at gmail.com> writes:
>>>> 2010/3/9 M?ns Rullg?rd <mans at mansr.com>:
>>>>> The build failures on mingw with gcc 4.2.4 are caused by the recent
>>>>> addition of -Werror=missing-prototypes triggering an error in
>>>>> stdio.h. ?For some reason, this gcc version isn't treating this as a
>>>>> system header and suppressing warnings.
>>>>>
>>>>> It might be possible to work around this by providing an explicit
>>>>> --sysroot argument to ffmpeg's configure. ?Could someone with an
>>>>> affected system please try this?
>>>>
>>>> --sysroot made no difference. I had to rebuild binutils for FFmpeg's
>>>> configure to accept sysroot, should I rebuild gcc with some other
>>>> option too?
>>>
>>> IIRC, gcc configure takes a --with-sysroot flag or similar.
>>>
>>>> from _mingw.h:
>>>> # if __GNUC_STDC_INLINE__
>>>> # ?define __CRT_INLINE extern inline __attribute__((__gnu_inline__))
>>>> # else
>>>> # ?define __CRT_INLINE extern __inline__
>>>> # endif
>>>>
>>>> from stdio.h:
>>>> #if !defined _MT
>>>>
>>>> __CRT_INLINE int __cdecl __MINGW_NOTHROW getc (FILE* __F)
>>>>
>>>> [...]
>>>>
>>>> #else ?/* Use library functions. ?*/
>>>>
>>>> _CRTIMP int __cdecl __MINGW_NOTHROW ? ? getc (FILE*);
>>>> _CRTIMP int __cdecl __MINGW_NOTHROW ? ? putc (int, FILE*);
>>>> _CRTIMP int __cdecl __MINGW_NOTHROW ? ? getchar (void);
>>>> _CRTIMP int __cdecl __MINGW_NOTHROW ? ? putchar (int);
>>>>
>>>> #endif
>>>>
>>>> in 4.2.2 that becomes (text vertically aligned):
>>>> extern __inline__ ? ? ? ? ? ? ? ? ? ? ? ? ? ? int
>>>> __attribute__((__cdecl__)) __attribute__ ((__nothrow__)) getc (FILE* __F)
>>>
>>> Right, now I remember the C99-compatible inline semantics are only
>>> available in gcc 4.3 and later. ?The earlier ones do something else,
>>> and do not define that macro.
>>>
>>> What this means is that the mingw headers do not work _at all_ with
>>> gcc 4.2. ?Try compiling two object files, both calling getc(), and
>>> link them together. ?Unless I am mistaken, you'll get a multiple
>>
>> Looks like it worked by pure luck:
>> $ cat getctest1.c
>> #include <stdio.h>
>> void foo1(void) { getc(NULL); }
>> $ cat getctest2.c
>> #include <stdio.h>
>> void foo2(void) { getc(NULL); }
>> $ i686-mingw32-gcc-4.2 -o getctest1.o -c getctest1.c
>> $ i686-mingw32-gcc-4.2 -o getctest2.o -c getctest2.c
>> $ i686-mingw32-gcc-4.2 -shared -o getctest.dll getctest1.o getctest2.o
>> $ i686-mingw32-objdump -d getctest.dll
>> [...]
>> 10001180 <_foo1>:
>> 10001180: ? ? ? 55 ? ? ? ? ? ? ? ? ? ? ?push ? %ebp
>> 10001181: ? ? ? 89 e5 ? ? ? ? ? ? ? ? ? mov ? ?%esp,%ebp
>> 10001183: ? ? ? 83 ec 08 ? ? ? ? ? ? ? ?sub ? ?$0x8,%esp
>> 10001186: ? ? ? c7 04 24 00 00 00 00 ? ?movl ? $0x0,(%esp)
>> 1000118d: ? ? ? e8 e6 03 00 00 ? ? ? ? ?call ? 10001578 <_getc>
>> 10001192: ? ? ? c9 ? ? ? ? ? ? ? ? ? ? ?leave
>> 10001193: ? ? ? c3 ? ? ? ? ? ? ? ? ? ? ?ret
>>
>> 10001194 <_foo2>:
>> 10001194: ? ? ? 55 ? ? ? ? ? ? ? ? ? ? ?push ? %ebp
>> 10001195: ? ? ? 89 e5 ? ? ? ? ? ? ? ? ? mov ? ?%esp,%ebp
>> 10001197: ? ? ? 83 ec 08 ? ? ? ? ? ? ? ?sub ? ?$0x8,%esp
>> 1000119a: ? ? ? c7 04 24 00 00 00 00 ? ?movl ? $0x0,(%esp)
>> 100011a1: ? ? ? e8 d2 03 00 00 ? ? ? ? ?call ? 10001578 <_getc>
>> 100011a6: ? ? ? c9 ? ? ? ? ? ? ? ? ? ? ?leave
>> 100011a7: ? ? ? c3 ? ? ? ? ? ? ? ? ? ? ?ret
>> [...]
>>
>
> Weird, why isn't it using the inline functions?
At -O1 and up it inlines the function, but at -O0 it just expects
there will bet a _getc to link to. For example if I add
__CRT_INLINE int __cdecl __MINGW_NOTHROW getxyz (FILE* __F)
{
return (--__F->_cnt >= 0)
? (int) (unsigned char) *__F->_ptr++
: _filbuf (__F);
}
to stdio.h and call getxyz(), it fails to link if optimizations are disabled.
More information about the ffmpeg-devel
mailing list