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

[John Calcote]

On 7/11/2010 3:40 PM, Eli Friedman wrote:
> On Sun, Jul 11, 2010 at 2:34 PM, John Calcote <john.calcote at gmail.com> wrote:
>   
>> On 7/11/2010 2:52 PM, Eli Friedman wrote:
>>     
>>> 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, what is the basis of your remarks?
>>
>> 1) I've searched the current publically available C99 standard (WG14
>> N1256 [C99 + TC1 + TC2 + TC3]
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf, referenced
>> from http://www.open-std.org/jtc1/sc22/wg14/www/standards) and I see no
>> references to _POSIX_C_SOURCE, either as a reserved identifier, or
>> otherwise. In fact the only reference to POSIX at all is found in the
>> Bibliography [entry 16] and refers only to Part II: Shell and Utilities.
>> If C99 had anything to say about POSIX as a standard, I would expect to
>> find a reference to it in section 2 Normative References, or at least in
>> the Appendices as informative references.
>>     
> C99 7.1.3p1 "All identifiers that begin with an underscore and either
> an uppercase letter or another underscore are always reserved for any
> use."
>   

That clause has been in the C standard since C89. It has nothing what
ever to do with C99, specifically, and it simply refers to the fact that
the compiler vendor may define identifiers beginning with underscore for
any purpose they wish without concern that they may be breaking existing
code bases. What does this have to do with the discussion at hand? It
certainly lends no credence to your arguments that all library symbols
(functions and global data) defined by POSIX are automatically
incorporated into the C99 standard if this symbol is defined and C99 has
to honor those symbols.

>> 2) Even if _POSIX_C_SOURCE was a reserved identifier (which you can see
>> from my first point is not true at all), it still would not follow that
>> POSIX can override anything the C99 standard says.
>>     
> C99 7.1.3p2 "If the program [,,,] defines a reserved identifier as a
> macro name, the behavior is undefined.
>   

All this clause says is that programs that define identifiers with
leading underscores may find themselves broken in the next release of
the compiler. Again I ask - what does this have to do with our
discussion of the possible ramifications of requesting both C99
compliance _and_ POSIX functionality on the same command line?

M?ns' last answer was the most reasonable so far: It works in non-cross
gcc, so it should work in cross gcc environments. But please don't try
to persuade me that this gray-area functionality is somehow part of the
C99 standard. C99 and POSIX have nothing to do with each other, except
that POSIX makes the statement that all library functions defined by C99
are incorporated into POSIX. This simply states that C99 is a proper
_subset_ of POSIX 2001. My original argument was: If C99 is indeed a
proper subset of POSIX, and ffmpeg needs POSIX functionality, then why
confuse things by asking the compiler to restrict your code base to C99
with one flag (--std=c99) and then turn around and ask it to also give
you access to all POSIX 2001 functionality (as superset of C99) with
another flag?

One responder suggested that --std=c99 had only to do with language
features. This isn't really true, as this flag also affects internal
preprocessor variables (that begin with underscores) that _disable_
various functions from the standard library too. Furthermore, without
the use of this option, the compiler will allow you access to the full
gamut of functionality provided by the compiler. Thus, the ONLY reason
to use it is to _restrict_ your code base to a particular standard.

John