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

[John Calcote]

On 7/11/2010 11:01 PM, David Conrad wrote:
> 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.
>   

This paragraph is completely self-contradictory:

1) "You're mistaken in thinking that -std=c99 is intended to prevent you
from using anything not in C99."
2) "gcc uses [it] to *disable incompatible language extensions* and
select the appropriate warnings; it still leaves in the compatible ones"

Can you not see that these two statements are direct contradictions of
each other? Part 2 is exactly what I'm saying: the -std flag is used to
*disable* anything the compiler would normally support that's not part
of the specified standard.

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

while -std=c99 disables language extensions, __STRICT_ANSI__ is a macro
defined by the compiler (when the -std option is used) to facilitate
disabling library extensions to the standard. Thus, -std=c99 is a
mechanism used purely to disabled language extensions AND library
extensions to the C99 standard.

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

This statement is nonsensical - gcc doesn't require anything - if it
did, who would be the party from which something is required? gcc is
self-contained - it provides a switch with certain semantics: language
and library extensions to the target standard are disabled when the
switch is used. The use of _POSIX_C_SOURCE in conjunction with -std=c99
is irrelevant; the two options have nothing to do with one another. The
result of using them together is a gray area, which I doubt very much
can be shown by any standard to mean any particular thing.

In fact, it's pure nonsense to use them together. On the one hand,
you're saying "compiler, please restrict my options in the language to
just those allowed by C99". On the other hand, you're saying, "compiler,
please allow me to use more than the C99 standard allows."

This is my whole point: using them together is undefined in the context
of any one standard, and therefore makes no sense. gcc chose to do one
thing with them, another vendor can chose to do something else.

John