[FFmpeg-devel] compile issues under mingw-cross-env

[David Conrad]

On Jul 11, 2010, at 12:55 AM, John Calcote wrote:

> On 7/10/2010 3:10 PM, Eli Friedman wrote:
>> On Sat, Jul 10, 2010 at 1:57 PM, Ramiro Polla <ramiro.polla at gmail.com> wrote:
>> 
>>> On Sat, Jul 10, 2010 at 5:53 PM, John Calcote <john.calcote at gmail.com> wrote:
>>> 
>>>> On 7/10/2010 1:25 PM, M?ns Rullg?rd wrote:
>>>> 
>>>>> John Calcote <john.calcote at gmail.com> writes:
>>>>> 
>>>>>> Anyone ever tried compiling ffmpeg under mingw-cross-env
>>>>>> (http://www.nongnu.org/mingw-cross-env/)? I've been playing with it and
>>>>>> I've found the following issues with CPPFLAGS in the generated config.mak:
>>>>>> 
>>>>>> 1) I had to change -std=c99 to -std=gnu99 because _STRICT_ANSI is
>>>>>> enabled if -std=c99 is used which means functions like strcasecmp aren't
>>>>>> available (at least the prototypes aren't).
>>>>>> 
>>>>>> 
>>>>> Wrong.  strcasecmp() is part of C99 and on any conforming system is
>>>>> declared when using those flags.
>>>>> 
>>>>> 
>>>> I'm not seeing strcasecmp as being part of C99. I'm seeing it as being
>>>> part of POSIX 2001... Are you sure you're correct on this one? When I
>>>> google search strcasecmp and c99, I get very little information on the
>>>> pair. However, most of what I do get appear to be comments about how
>>>> ffmpeg doesn't compile under mingw.
>>>> 
>>> 'man standards' says:
>>> "POSIX.1-2001 is aligned with C99, so that all of the library
>>> functions standardised in C99 are also standardised in POSIX.1-1001."
>>> 
>> strcasecmp is defined in strings.h, which is not part of C99.  So
>> -std=c99 vs. -std=gnu99 shouldn't have any affect.
>> 
> 
> I don't think this is an accurate assessment of the way these flags
> work. In the first place, gnu99 is technically less restrictive than
> c99. However, the real issue, in my experience, with compiler flags that
> ask for compliance with a standard is that they tend to be
> compound-restrictive, not compound-additive. That is to say these flags
> are designed to ensure that only the subset of library routines that
> comply with the requested standard are available, and that uses of all
> other routines are flagged as errors.
> 
> To put it another way, they're not designed to provide access to a
> specific set of functions, but to disallow anything outside the desired
> set. The reason for this approach is that the flags are designed to help
> developers write portable code. If you know that three target platform
> tool sets all conform to C99, and you use the --std=c99 flag on the gcc
> command line, then you're telling gcc that you don't want to allow
> anything _except_ C99-compliant functions, not that you want to ensure
> that you have access to all C99 functions. That way, you can be sure
> your code will compile on your other two platforms.
> 
> Thus, if you supply flags that say you want C99 _and_ POSIX 2001, you're
> likely (on some platforms, at least) to get the intersection of the two
> sets, not the union of them. Often this situation goes unnoticed because
> the these two sets overlap to a high degree (in fact C99 is completely
> contained within POSIX 2001).

strcasecmp is required to be in POSIX 2001 [1], and if you define _POSIX_C_SOURCE to 200112L then #include <strings.h> is required to make said symbol visible [2].

So in this case it's mingw that's wrong.

[1] http://www.opengroup.org/onlinepubs/009695399/basedefs/strings.h.html
[2] http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html