"Fat" binaries for OS X (was Re: [GENERAL] Postgres Library natively available for Mac OSX Intel?) - Mailing list pgsql-hackers

From Tom Lane
Subject "Fat" binaries for OS X (was Re: [GENERAL] Postgres Library natively available for Mac OSX Intel?)
Date
Msg-id 2820.1144550087@sss.pgh.pa.us
Whole thread Raw
Responses Re: "Fat" binaries for OS X (was Re: [GENERAL] Postgres Library natively available for Mac OSX Intel?)  (Philipp Ott <philipp.ott@avalon.at>)
List pgsql-hackers
Philipp Ott <philipp.ott@avalon.at> 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
architectureby 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
usinglipo(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


pgsql-hackers by date:

Previous
From: "Luke Lonergan"
Date:
Subject: Re: Support Parallel Query Execution in Executor
Next
From: Bruce Momjian
Date:
Subject: Re: Get explain output of postgresql in Tables