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

Eli Friedman eli.friedman
Sun Jul 11 22:52:27 CEST 2010


On Sun, Jul 11, 2010 at 1:33 PM, John Calcote <john.calcote at gmail.com> wrote:
> On 7/10/2010 11:11 PM, David Conrad wrote:
>> 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
>>
>
> David, your statement is 100 percent true but you missed my point
> entirely. Basically, -std=c99 and _POSIX_C_SOURCE=200112L are
> conflicting flags that, when used together, give undefined results. It's
> cool that the results you've gotten so far are what you wanted, but you
> can't count on those results on all platforms because the results of
> using the two together is not defined by any standard.

The conflict in question doesn't exist.  _POSIX_C_SOURCE is a reserved
identifier in C99, so defining it means that POSIX can override
anything the C99 standard says.

-Eli



More information about the ffmpeg-devel mailing list