Tom:
> 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