[PD] Re: [PD-announce] Pd compiled for imac

Miller Puckette mpuckett at imusic1.ucsd.edu
Sun May 28 01:58:40 CEST 2006

Looks like it works, for dylibs and execs both.  I'll start making
fat-binary externs for mac (not sure if I can get Pd itself to work as
a fat binary but the externs are the really essential thing.)


On Sun, May 28, 2006 at 01:20:57AM +0200, Hans-Christoph Steiner wrote:
> On May 28, 2006, at 1:07 AM, chris clepper wrote:
> >On 5/27/06, Hans-Christoph Steiner <hans at eds.org> wrote:
> >
> >On May 28, 2006, at 12:22 AM, Miller Puckette wrote:
> >
> >> Yep... I thought 'imac' meant 'intel-mac' but I guess it doesn't.
> >>
> >> Anyway, I think that if someone wants to publish an extern that  
> >works
> >> on either mips or i86 macs, they would have to include both
> >> "dylib"s...
> >> unless there's a way to make a fat dylib with binaries for both
> >> architectures.
> >
> >Apple provides two mechanisms for this, one is fat binaries, which
> >have been supported since NeXTSTEP 3.2 (Mac OS X 10.4 == NeXTSTEP
> >6.4), and the other is Rosetta, which runs PPC code in emulation.
> >NeXTSTEP/Apple uses gcc for everything, so building fat binaries is
> >just a matter of figuring out the gcc options.
> >
> >A fat binary only solves the executable problem.  The externals are  
> >just as much a headache to deal with as the Pd app - maybe more.
> If its just a matter of giving some flags to gcc, which I think it  
> is, then it would be _much_ easier to add those flags to the relevant  
> makefiles than to deal with a new file extension.
> >The catch with Rosetta is that you cannot load a PPC lib into an  
> >Intel application or vice versa.  This is going to become slightly  
> >tricky to make sure people get the proper OSX externals that match  
> >their CPU type.
> >
> >I don't think fat dylibs exist -it would be a useful thing to have  
> >though.
> I think fat dylibs do exist (from a Slashdot thread):
> http://apple.slashdot.org/article.pl?sid=05/08/24/2114232
> OS X 10.4 uses fat binaries. For example, Apple recently botched a  
> security update by failing to ship a fat binary for the BSD layer.  
> This is what it's supposed to look like:
>     $ file /usr/lib/libSystem.B.dylib
>     /usr/lib/libSystem.B.dylib: Mach-O fat file with 2 architectures
>     /usr/lib/libSystem.B.dylib (for architecture ppc): Mach-O  
> dynamically linked shared library ppc
>     /usr/lib/libSystem.B.dylib (for architecture ppc64): Mach-O 64- 
> bit dynamically linked shared library ppc64
> Apple's GCC has built-in support for fat binaries:
>     $ gcc -o hello hello.m -arch ppc -arch ppc64
>     $ file hello
>     hello: Mach-O fat file with 2 architectures
>     hello (for architecture ppc): Mach-O executable ppc
>     hello (for architecture ppc64): Mach-O 64-bit executable ppc64
> If I had the right SDK installed, I could have added -arch i386.  
> Building fat binaries with GCC and ICC will probably require the use  
> of lipo(1).
> .hc
> ________________________________________________________________________ 
> ____
> "I have the audacity to believe that peoples everywhere can have  
> three meals a day for their bodies, education and culture for their  
> minds, and dignity, equality and freedom for their spirits."
>                                             - Martin Luther King, Jr.

> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

More information about the Pd-list mailing list