Philipp Ott <[EMAIL PROTECTED]> writes: > Currently 8.1.3 compiles and runs just fine on OSX 10.4.6 + XCode > 2.2.1, but generates binaries just for the current host architecture. > Now when I add -arch i386 -arch ppc to CFLAGS and LDFLAGS for > configure, then it compiles everything just fine, however at linking > stage I get various problems for missing architecture files.
I looked into this and found that the problem is our habit of using "ld -r" to aggregate multiple .o files into a single SUBSYS.o file that's still relocatable. The Darwin version of ld is pretty brain-dead when it comes to "fat" files containing code for more than one architecture --- the man page says UNIVERSAL FILE SUPPORT The link editor accepts ``universal'' (multiple-architecture) input files, but always creates a ``thin'' (single-architecture), standard Mach-O output file. The architecture is specified using the -arch arch_type option. If this option is not used, ld(1) attempts to deter- mine the output architecture by examining the first object file encoun- tered on the command line. If it is a ``thin'' file, its architecture determines that of the output file. If the first input file is a ``universal'' file, the ``best'' architecture for the host is used. (See the explanation of the -arch option, below.) The compiler driver cc(1) handles creating universal executables by calling ld(1) multiple times and using lipo(1) to create a ``univer- sal'' file from the results of the ld(1) executions. So what you're seeing is that one of the arches has been dropped from the SUBSYS.o files. Unfortunately, there doesn't seem to be any way to use cc/gcc to emulate "ld -r", in the sense of just combining multiple fat .o files into one fat .o file. At least I couldn't see one after perusing the man page for a bit. I also found out that lipo(1) is not by itself smart enough to do this. So it looks like you'd have to write a small shell script to do what the above snippet describes cc as doing. Not out of the question by any means, but still a PITA. Any Apple experts around who know a better answer? Is Apple likely to improve this situation in the near future? BTW, our configure script is not real flexible about adjusting the command used to produce the SUBSYS.o files ... if you want anything except "$(LD) -r -o SUBSYS.o *.o", you have to edit Makefile.global after configuring. But without having a solution that actually works for multi-arch Darwin, I'm not seeing the point of improving that yet. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings