In article <8hpgn7fho...@mid.individual.net>, Gregory Ewing <greg.ew...@canterbury.ac.nz> wrote:
> Ned Deily wrote: > > Perhaps you're > > calling ld(1) directly? To link multiple-arch executables (etc), the > > Apple gcc driver does the dirty work of calling ld multiple times and > > lipo-ing the results. > > Is this something that only works at link time, then? The > gcc man page says: > > "Multiple options work, and > direct the compiler to produce "universal" binaries including > object code for each architecture specified with -arch." > > From this I was hoping to be able to do > > gcc -arch i386 -arch x86_64 -c foo.c > > and get dual-architecture .o files that could then be linked > into dual-architecture libraries. But if I do the above, I > just get an x86_64 .o file. > > Are you saying that I need to compile separate sets of .o > files and then combine them at link time? That sounds like > an awkward thing to retrofit onto a library's existing > build system. No, it's supported both at compile and link time. Here's a compile on 10.6: $ /usr/bin/gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ /usr/bin/gcc -arch i386 -arch x86_64 -c foo.c $ file foo.o foo.o: Mach-O universal binary with 2 architectures foo.o (for architecture i386): Mach-O object i386 foo.o (for architecture x86_64): Mach-O 64-bit object x86_64 BTW, if, for some reason, you *do* need to extract a particular architecture from a multi-arch file, you can use lipo to do it: $ lipo foo.o -output foo_32.o -extract i386 $ lipo foo.o -output foo_64.o -extract x86_64 $ file foo_32.o foo_32.o: Mach-O universal binary with 1 architecture foo_32.o (for architecture i386): Mach-O object i386 $ file foo_64.o foo_64.o: Mach-O universal binary with 1 architecture foo_64.o (for architecture x86_64): Mach-O 64-bit object x86_64 -- Ned Deily, n...@acm.org -- http://mail.python.org/mailman/listinfo/python-list