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

[Måns Rullgård]

John Calcote <john.calcote at gmail.com> writes:

> M?ns,
>
> 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
them?

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

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

-- 
M?ns Rullg?rd
mans at mansr.com