[Ffmpeg-devel] [PATCH] Universal binary support for Mac OS X

[Dan Villiom Podlaski Christiansen]

On 05/02/2006, at 14.30, Diego Biurrun wrote:

> On Sat, Feb 04, 2006 at 07:39:27PM +0100, Dan Villiom Podlaski  
> Christiansen wrote:
>>
>> Attached below is a patch which adds a new CPU type to the FFmpeg
>> configure system, 'fat'. This is used for building a universal binary
>> on Mac OS X 10.4, which runs natively both on PowerPC and x86
>> systems. Also added is an easier way to access this this flag, '--
>> enable-universal'. Additionally, tuning for all four CPU families
>> that Mac OS X runs on, G3, G4, G5 and Intel, is also possible by
>> specifying '--tune=all'. To my knowledge, this has no benefits beyond
>> resulting in a binary that takes four times as long to compile and is
>> four times as large as a non-fat binary, rather than the ordinary
>> universal binary which just doubles the time and space required.
>
> I've been wondering about this fat binary thing for some time, I'm not
> sure if it's a good idea in the first place.  Then again, it's  
> probably
> here to stay..

There are two ways to generate a fat binary: Either by passing more  
than one -arch flag to GCC and/or ld, or by separately building a  
binary for each architecture and combine them with 'lipo'. Adding  
cross-compiling support to FFmpeg would probably require at least as  
many changes as just doing the fat binary all at once.

Mac applications that use FFmpeg ? such as VLC ? will need a fat  
FFmpeg as they move to universal binaries.

>
>> While at it, I added the 'safe' flags that are used in Apple's -fast
>> option to GCC 4, which should generate slightly faster binaries.
>
> Please send a separate patch for this.
>
>> I hope the changes are acceptable for FFmpeg. If not, please tell me
>> what needs to be fixed.
>
> I've only had a quick cursory glance at your patch.  At 48k it's quite
> big and would probably be easier to review if you could break it up  
> into
> a few easier to digest pieces.

Will a split in PPC source changes, x86 source changes, remaining  
source changes and build system changes do?

>> --- configure	2 Feb 2006 13:07:29 -0000	1.242
>> +++ configure	4 Feb 2006 18:06:21 -0000
>> @@ -1070,7 +1117,7 @@
>> -if $cc $CFLAGS $LDFLAGS $extralibs -o $TMPE $TMPC 2> /dev/null ;  
>> then
>> +if $cc $CFLAGS $LDFLAGS $extralibs -o $TMPE $TMPC 2> /dev/null; then
>> @@ -1475,8 +1577,9 @@
>> -  echo "#define EMULATE_FAST_INT 1" >> $TMPH
>> +    echo "#define EMULATE_FAST_INT 1" >> $TMPH
>
> cosmetics

Indeed, removed.

>
>> --- libavcodec/dsputil.h	12 Jan 2006 22:43:15 -0000	1.126
>> +++ libavcodec/dsputil.h	4 Feb 2006 18:06:21 -0000
>> @@ -468,7 +468,7 @@
>> -#if defined(HAVE_ALTIVEC) && !defined(CONFIG_DARWIN)
>> +#if defined(HAVE_ALTIVEC) && defined(HAVE_ALTIVEC_H)
>
> Won't just 'defined(HAVE_ALTIVEC_H)' suffice?

Yes, it ought to be enough.

>
>> --- libavcodec/i386/cputest.c	22 Dec 2005 01:10:09 -0000	1.16
>> +++ libavcodec/i386/cputest.c	4 Feb 2006 18:06:21 -0000
>> @@ -4,6 +4,8 @@
>>  #include "../dsputil.h"
>>
>> +#ifdef HAVE_MMX
>> +
>> @@ -129,3 +131,5 @@
>> +
>> +#endif /* HAVE_MMX */
>
> I dislike putting #ifdef around complete file contents.  The build
> system should take care of this instead and compile the file only  
> if the
> #ifdef condition is fulfilled.

There really is no way around this without significantly changing the  
build system or adding some hacks to the Makefile. The point is that  
the GCC driver executes a subinstance with the very same arguments  
for each architecture. I can't think of a way of preventing one of  
the instances from compiling a file, other than source code macros.

--

- Dan Villiom Podlaski Christiansen