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

[Rich Felker]

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

I can't even believe I'm reading this.... this is either so incredibly
sad or so incredibly funny and I can't figure out which. Certainly the
most ridiculous macism I've ever heard of. You can write me off if you
like because I don't have any authority to make a decision on this,
but I'm against adding tons of bloat to ffmpeg's build system to
support such an ugly hack.

If ffmpeg doesn't build successfully under a cross-compiler, this
should be fixed. It may require just as many changes, but it would
help lots of architectures and help in situations that make sense,
rather than just helping to bloat your binaries. (Then mac users who
want the dual binary behavior can use the separate 'lipo' program.)

BTW, do mac developers really consider their users so stupid that they
can't figure out which binary to download, and that they need to waste
twice the download time and disk space to make sure they have the
right binary? If so I find this really insulting to users, and sad..

Rich