Hi, On OSX, how can we build universal binaries for externals ? If not possible, both ppc and intel architecture use the .pd_darwin suffix...
Thanks,
Hi,
On OSX, how can we build universal binaries for externals ? If not possible, both ppc and intel architecture use the .pd_darwin suffix...
the easiest approach is to make separate externals for each architecture (like ppc, ppc64, i386) and glue them together with lipo.
lipo -create myext.i386.pd_darwin myext.ppc.pd_darwin -output myext.pd_darwin
The flext build system uses a slightly different approach by compiling architecture-specific object files (because the compiler flags may be architecture-specific), use lipo to make UB object files and then call the linker with something like g++ -dynamic -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -o myext.pd_darwin objectfiles....
greetings, Thomas
Thanks Thomas ! Is this what is done in pd-extended ? I guess not.
a
2007/11/25, Thomas Grill gr@grrrr.org:
Hi,
On OSX, how can we build universal binaries for externals ? If not possible, both ppc and intel architecture use the .pd_darwin suffix...
the easiest approach is to make separate externals for each architecture (like ppc, ppc64, i386) and glue them together with lipo.
lipo -create myext.i386.pd_darwin myext.ppc.pd_darwin -output myext.pd_darwin
The flext build system uses a slightly different approach by compiling architecture-specific object files (because the compiler flags may be architecture-specific), use lipo to make UB object files and then call the linker with something like g++ -dynamic -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -o myext.pd_darwin objectfiles....
greetings, Thomas
You can skip the lipo step, gcc will do it for you if you provide the
right flags. You can also include 64-bit in there. If you want to
do specific optimizations for each CPU, then you'll have to build
each separately and use lipo to assemble them all into one.
CFLAGS="-arch i386 -arch ppc -arch x86_64 -arch ppc64"
LDFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch
ppc -arch x86_64 -arch ppc64"
Pd-extended is not universal (yet?). I think it should be, it's just
a matter of someone doing the work.
.hc
On Nov 25, 2007, at 5:49 PM, Alexandre Quessy wrote:
Thanks Thomas ! Is this what is done in pd-extended ? I guess not.
a
2007/11/25, Thomas Grill gr@grrrr.org:
Hi,
On OSX, how can we build universal binaries for externals ? If not possible, both ppc and intel architecture use
the .pd_darwin suffix...the easiest approach is to make separate externals for each
architecture (like ppc, ppc64, i386) and glue them together with lipo.lipo -create myext.i386.pd_darwin myext.ppc.pd_darwin -output myext.pd_darwin
The flext build system uses a slightly different approach by
compiling architecture-specific object files (because the compiler flags may be architecture-specific), use lipo to make UB object files and then
call the linker with something like g++ -dynamic -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -o myext.pd_darwin objectfiles....greetings, Thomas
-- Alexandre Quessy http://alexandre.quessy.net http://www.puredata.info/Members/aalex
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
Alexandre Quessy wrote:
Hi, On OSX, how can we build universal binaries for externals ? If not possible, both ppc and intel architecture use the .pd_darwin suffix...
this is not fully true. the "new" (as with pd-0.41, probably even 0.40) extensions for externals on os-x are: .d_ppc: darwin powerpc .d_fat: darwin powerpc+i686 combined
.pd_darwin is still supported for legacy externals.
how to build them: look at pd/extra/Makefile
mf.asdr IOhannes
On Nov 26, 2007, at 3:43 AM, IOhannes m zmoelnig wrote:
Alexandre Quessy wrote:
Hi, On OSX, how can we build universal binaries for externals ? If not possible, both ppc and intel architecture use
the .pd_darwin suffix...this is not fully true. the "new" (as with pd-0.41, probably even 0.40) extensions for
externals on os-x are: .d_ppc: darwin powerpc .d_fat: darwin powerpc+i686 combined.pd_darwin is still supported for legacy externals.
how to build them: look at pd/extra/Makefile
Pd-extended only builds objects using .pd_darwin as an extension. It
works fine for i386, PowerPC, and universal binaries.
.hc
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Hans-Christoph Steiner wrote:
On Nov 26, 2007, at 3:43 AM, IOhannes m zmoelnig wrote:
.pd_darwin is still supported for legacy externals.
Pd-extended only builds objects using .pd_darwin as an extension. It
works fine for i386, PowerPC, and universal binaries.
but then, pd-extended _is_ a legacy project (no harm intended from my side; there is nothing wrong with that)
once Pd-extended grows to 0.41, chances are high that it will support the .d_fat idiom too. in the meantime, we can argue whether it was a good idea to have different suffixes for different OS's _and_ architectures (but why should we?)
gmadsr IOhannes
On Nov 27, 2007, at 3:34 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Nov 26, 2007, at 3:43 AM, IOhannes m zmoelnig wrote:
.pd_darwin is still supported for legacy externals.
Pd-extended only builds objects using .pd_darwin as an extension.
It works fine for i386, PowerPC, and universal binaries.but then, pd-extended _is_ a legacy project (no harm intended from
my side; there is nothing wrong with that)once Pd-extended grows to 0.41, chances are high that it will
support the .d_fat idiom too. in the meantime, we can argue whether it was a good idea to have
different suffixes for different OS's _and_ architectures (but why
should we?)
Actually, Pd-extended will stick to .pd_darwin as the default unless
someone else really wants to change it. .d_fat was introducted in
0.40, and the current Pd-extended still uses .pd_darwin.
.hc
Access to computers should be unlimited and total. - the hacker ethic