On Feb 4, 2008, at 1:25 PM, Tom Lane wrote:
"Dave Page" <dpage@xxxxxxxxxxxxxx> writes:
The Mac build of EDB Postgres is universal throughout,
Yeah? How painful is it? We've had more than one request to enable
universal builds.
regards, tom lane
Here is a config file I tried
mbp:postgresql-8.3.0 postgres$ more configJHLFat
./configure --bindir=/usr/local/bin --mandir=/usr/local/share/man \
--enable-thread-safety \
--enable-multibyte --with-perl --with-tcl \
--with-python --with-libedit-preferred \
--with-openssl --with-bonjour \
CFLAGS='-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch
ppc' \
LDFLAGS='-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -
arch i386' \
LDFLAGS_SL='-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch
ppc -arch i386' \
MACOSX_DEPLOYMENT_TARGET=10.4
I tried for a while to build the rascal and found the sticky
point was invoking "ld".
The man page for ld asserts that ld will only output a "thin"
object file.
In particular all of the SUBSYS.o files would default to
plain old mach-o files. Eventually this caused problems
during later linking.
The man page for ld tantalized me by stating that
gcc would automagically be enabled to build fat
objects an invoke lipo to build a fat object.
All of the *.o files generated by gcc where in fact
fat object files.
In fact I went to the interfaces directory and into
the libpq subdirectory and invoked make and was able
to build a "fat" libpq.a
I was able to build an intel binary without any problems but
it will be a couple of days before I find out if the "fat" libpq.a
is actually functional ;(
Jerry
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
