[FFmpeg-devel] FATE failure on mingw gcc-4.2.4

[Måns Rullgård]

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

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

Yes, of course...  It's all coming back to me now.  In gcc 4.2 and
earlier the meaning of extern on an inline function is almost the
exact reverse of that in the C99 standard, even with -std=c99
specified.

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