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

[Eli Friedman]

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

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

-Eli