BTW, is anyone interested in looking into whether we can be made to build without using either flag? I tried it and saw a number of failures that looked like they traced to incompatible macro expansion. This wouldn't surprise me if PG were some halfbaked package that only got tested with stock GCC, but considering that we actually build fine on quite a range of compilers, it seems like Apple's cpp ought to work too. It would be interesting to understand what the problem is.
Does this happen with gcc 3.3? My understanding is that pre-3.3, the default C preprocessor was cpp-precomp, a NeXT-era concoction that supports precompiled header files for Objective-C. This preprocessor is about as bad as it seems to be, so even Apple recommends turning it off for other languages.
In gcc 3.3, Apple has generalized the precompiled headers feature to a mainline gcc feature called PFE, so cpp-precomp should be history. If I've gotten this right, you shouldn't get (the same) compiler errors with gcc 3.3 if you leave out the -no-cpp-precomp switch.
. . .
While we're on a Mac-related note, I managed to compile PostgreSQL on Mac OS X 10.2 Jaguar with two-level namespace support. <http://developer.apple.com/documentation/ReleaseNotes/DeveloperTools/ TwoLevelNamespaces.html> This is quite useful, so I hope you can look into incorporating the changes.
http://www.markokarppinen.com/pg-two-level-namespace.diff
This involves getting rid of undefined symbols in all shared libraries (or "bundles") that get built. I tested this with "./configure" and "./configure --with-tcl" but didn't try the jdbc or python extensions. Hopefully someone else can test those, and if all seems fine, commit the changes.
Thanks, Marko
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
