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

[Måns Rullgård]

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?

> https://sourceforge.net/tracker/?func=detail&aid=2968618&group_id=2435&atid=102435
>
> Should we document that users should
>
> -#if !defined _MT
> +#if 0
>
> when using mingw gcc 4.2?

If they refuse to fix their headers, I'll consider adding a check to
see if that flag is safe with system headers.

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