Awhile back we determined that the big stumbling block for building Postgres universal binaries for OS X was that we were using "ld" to produce intermediate SUBSYS.o files, and it didn't want to preserve multi-architecture components of input .o files. Peter got rid of that hack recently, so I thought I'd see what it takes to build a universal binary with CVS HEAD.
The good news is that the tools problem seems to be solved. If you add something like "-arch i386 -arch ppc" to CFLAGS and build normally, you get real working multiarch binaries and libraries. (At least it works for me on OS X 10.5.4 --- no promises about older toolchains.) The bad news is that if you only do that, only the arch that you actually build on will work. We have configure set up to insert various hardware-dependent definitions into pg_config.h and ecpg_config.h, and if you don't have the right values visible for each compilation, the resulting executables will fail. You can get around that by hacking up the generated config files with #ifdef __i386__ and so on to expose the correct values of the hardware-dependent symbols to each build. Of course you have to know what the correct values are --- if you don't have a sample of each architecture handy to run configure against, it'd be easy to miss some things. And even then it's pretty tedious. I am not sure if it is possible or worth the trouble to try to automate this part better. The other big problem is that genbki.sh wants to propagate some of those hardware-dependent symbols into postgres.bki, in particular FLOAT4PASSBYVAL and FLOAT8PASSBYVAL. This is a complete nonstarter, because we put postgres.bki under share/ which means it is supposed to be architecture independent. (I'm really glad I realized this before we released 8.4, because it'd violate Red Hat's multilib file rules...) I think we can pretty easily fix that by moving the responsibility for substituting these values into initdb, though. Modulo the above problems, I was able to build i386+ppc binaries that do in fact work on both architectures. I haven't got any 64-bit Apple machines to play with, so there might be 64-bit issues I missed. Still, this is a huge step forward compared to what was discussed here: http://archives.postgresql.org/pgsql-general/2008-02/msg00200.php regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
