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

[John Calcote]

On 7/11/2010 3:40 AM, M?ns Rullg?rd wrote:
> David Conrad <lessen42 at gmail.com> writes:
>
>   
>> 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.
>>>       
> This is inaccurate.  In the gcc manual, the description of the -std=
> flag mentions only _language_ extensions (additional keywords etc.),
> nothing about library support.  GCC is, after all, a compiler, not a C
> library.
>
>   
>>> 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).
>>>       
> That is in stark contradiction to what the POSIX spec says.  The
> description of the _POSIX_C_SOURCE macro makes no exceptions.
>   

What could the POSIX spec possibly have to say about anything outside of
the scope of the POSIX spec? For example, let's say, for the sake of
argument, that you're using a compiler that supports a hypothetical
switch, --disable-all-extension-macros, which does what its name
implies. If you use this switch in conjunction with _POSIX_C_SOURCE, how
would you expect the POSIX spec to discuss interaction with such a
switch? Frankly, it's not reasonable to assume the POSIX spec would have
_anything_ to say about it. Thus, what would POSIX have to say about the
use of a --std=c99 switch.

>   
>> 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].
>>     
> Small correction, _XOPEN_SOURCE must be set to 600 as well.
> strcasecmp() is part of the XSI extensions.
>
>   
>> So in this case it's mingw that's wrong.
>>     
> It could be argued that mingw isn't attempting to be POSIX-compliant
> at all, and hence is not "wrong" per se.  It would, however, be
> reasonable of them to follow the spec for the subset they do provide.
>   

For the record, I believe mingw is doing something odd. The entire goal
of their project is to provide a Windows portability mechanism for Unix
source code. It seems silly to not support something widely done in the
Unix world.

John