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

Diego Biurrun diego
Sun Feb 5 16:07:45 CET 2006


On Sun, Feb 05, 2006 at 03:23:07PM +0100, Dan Villiom Podlaski Christiansen wrote:
> 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:
> >
> >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.

I just tend to think that universal binaries are a bad idea.  Then again
I'm pretty sure I'll be fighting windmills if I try to oppose them.  If
people want them, so be it.

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

I think so, yes.

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

Hacks to the Makefile are better than hacks in the source IMO.

Diego





More information about the ffmpeg-devel mailing list