[FFmpeg-devel] compile issues under mingw-cross-env
Sat Jul 10 23:10:21 CEST 2010
John Calcote <john.calcote at gmail.com> writes:
> 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.
Sorry, it seems I had it confused with something else. Nevertheless,
if it has POSIX functions and we ask for POSIX, why doesn't it supply
>>> 2) I had to remove the definition of _POSIX_C_SOURCE=200112 because
>>> defining it causes pid_t to not be defined in sched.h.
>> Wrong again. We do not use sched.h at all. We include sys/wait.h,
>> which defers to sys/types.h for the pid_t type. The standard requires
>> that sys/types.h define pid_t with no extra conditions imposed.
> You're probably unaware of how pid_t is defined through sched.h via
> mingw's pthread.h file. I'm not trying to tell you you're wrong - I'm
> sure this is a very platform (mingw) specific thing.
How mingw defines pid_t is none of my concern. Since it, apparently,
does have the unistd.h and sys/wait.h headers, it is insane of it not
to define the types these are _required_ to provide by the standard
they came from in the first place (I realise mingw is not a full POSIX
>>> After making these changes in the generated config.mak file, ffmpeg and
>>> utilities compiled - not cleanly, mind you, but at least as cleanly as
>>> it does in normal non-cross builds.
>> What is that supposed to mean? Condescending remarks like that will
>> not win our hearts.
> I'm sorry. I really didn't mean to sound condescending. I can see how it
> came across that way. I was simply trying to say that there aren't any
> more warnings than there normally are. Please accept my apologies.
Warnings != unclean. Those who insist on having no warnings have
obviously never written code to be compiled with over a dozen
different compilers. Keeping them all warning-free at the same time
is generally impossible.
mans at mansr.com
More information about the ffmpeg-devel