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

David Conrad lessen42
Mon Jul 12 07:01:42 CEST 2010


On Jul 11, 2010, at 4:33 PM, John Calcote 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.

They aren't. You're mistaken in thinking that -std=c99 is intended to prevent you from using anything not in C99. It's a gcc flag used to select a base language standard. [1]  gcc uses to disable incompatible language extensions and select the appropriate warnings; it still leaves in the compatible ones.

gcc also defines __STRICT_ANSI__ with -std=c99, which header files may use to hide symbols not in C99. However as I pointed out, POSIX requires that if _POSIX_C_SOURCE is defined, POSIX headers must declare POSIX functions regardless of other macro definitions, including __STRICT_ANSI__.

Even without _POSIX_C_SOURCE, gcc does not require libc headers to hide anything when __STRICT_ANSI__ is defined, and obviously C99 itself says nothing about this.

[1] http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/C-Dialect-Options.html



More information about the ffmpeg-devel mailing list