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

John Calcote john.calcote
Sat Jul 10 22:53:30 CEST 2010


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.

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

$ make V=1
i686-pc-mingw32-gcc -I. -I"/home/jcalcote/dev/svn/ffmpeg-trunk/svn"
-D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -DHAVE_AV_CONFIG_H -std=gnu99 -fno-common
-fomit-frame-pointer -g -Wdeclaration-after-statement -Wall -Wno-switch
-Wdisabled-optimization -Wpointer-arith -Wredundant-decls
-Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef
-Wmissing-prototypes -O3 -fno-math-errno -fno-signed-zeros
-fno-tree-vectorize -Werror=implicit-function-declaration
-Werror=missing-prototypes          -MMD -MF libavcodec/pthread.d -MT
libavcodec/pthread.o -c -o libavcodec/pthread.o
/home/jcalcote/dev/svn/ffmpeg-trunk/svn/libavcodec/pthread.c
In file included from
/opt/mingw-cross-env-2.15/usr/bin/../lib/gcc/i686-pc-mingw32/4.5.0/../../../../i686-pc-mingw32/include/pthread.h:289:0,
                 from
/home/jcalcote/dev/svn/ffmpeg-trunk/svn/libavcodec/pthread.c:24:
/opt/mingw-cross-env-2.15/usr/bin/../lib/gcc/i686-pc-mingw32/4.5.0/../../../../i686-pc-mingw32/include/sched.h:153:53:
error: expected ')' before 'pid'
/opt/mingw-cross-env-2.15/usr/bin/../lib/gcc/i686-pc-mingw32/4.5.0/../../../../i686-pc-mingw32/include/sched.h:155:53:
error: expected ')' before 'pid'
make: *** [libavcodec/pthread.o] Error 1


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.

>   
>> I used the following command line to configure:
>>
>> $ configure --enable-postproc --enable-gpl --enable-x11grab
>> --enable-pthreads --enable-nonfree --enable-libvorbis
>> --target-os=mingw32 --enable-memalign-hack --arch=x86_64
>> --cross-prefix=i686-pc-mingw32-
>>
>> Note this is a 64-bit windows build (arch=x86_64).
>>     
> The combination of 64-bit and mingw is likely a recipe for trouble.
> Maybe the cross-tools are better than regular mingw, I don't know.
>   

What I like about cross-env is that it's actually being maintained
regularly. I've tried various other platforms and tool sets, but I've
not been able to find anything that works as well as this project.

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

Thanks for the comments,
John



More information about the ffmpeg-devel mailing list