[Ffmpeg-devel] [PATCH] Universal binary support for Mac OS X
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.
More information about the ffmpeg-devel