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

John Calcote john.calcote
Sun Jul 11 06:30:07 CEST 2010


Hi Ramiro,

On 7/10/2010 2:57 PM, Ramiro Polla 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."
>   

That's reverse logic. Just because all of C99 is part of POSIX 2001,
doesn't mean all of POSIX 2001 is part of C99. The original point was
that strcasecmp is part of POSIX 2001, but not necessarily part of C99.
The original problem was due to the fact that strcasecmp was being used
in a standards-compliant C99 environment.

Listen folks, I'm not trying to be "right" about anything here. I'm just
trying to solve a problem and (within the limits of reason) I don't
really care how it gets solved. My original post was more a query than
anything else about what the rest of the community is doing about these
issues. So far, all I'm hearing on this list is that the ffmpeg code
base is right and everyone else is wrong. That's not very helpful. I
took a look at the previously referenced defects that were closed with
will-not-fix on the mingw list. I'm not saying the mingw folks are
right, nor am I saying they're smarter than this community. But they
work on compilers and this community works on video and audio conversion
software. It wouldn't hurt to give them a listen - they might have a
valid point.

Regards,
John




More information about the ffmpeg-devel mailing list