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

[Måns Rullgård]

David Conrad <lessen42 at gmail.com> writes:

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

This is inaccurate.  In the gcc manual, the description of the -std=
flag mentions only _language_ extensions (additional keywords etc.),
nothing about library support.  GCC is, after all, a compiler, not a C
library.

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

That is in stark contradiction to what the POSIX spec says.  The
description of the _POSIX_C_SOURCE macro makes no exceptions.

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

Small correction, _XOPEN_SOURCE must be set to 600 as well.
strcasecmp() is part of the XSI extensions.

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

It could be argued that mingw isn't attempting to be POSIX-compliant
at all, and hence is not "wrong" per se.  It would, however, be
reasonable of them to follow the spec for the subset they do provide.

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

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