Eric Smith <eric_h_smith@mac.com> writes:
> You are correct. On an Intel, the failed command I mentioned earlier
> works just fine.
> I'm building for, and running on, both PPC and Intel. I've been able
> to avoid these snags in the past, but I'm now adding user management
> to the app, and I'm dead in the water on the PPC.
Just for fun, I tried to reproduce this. I couldn't figure out what
you'd done to build a dual-arch version of 8.3 --- it certainly would
take more than just passing some funny FLAGS settings to configure.
With CVS HEAD though, the build *does* go through with only a couple
of minor bleats from ranlib, given
CFLAGS='-arch i386 -arch ppc' LDFLAGS='-arch i386 -arch ppc' configure ...
Building this way on x86 OSX 10.5.6, the resulting binaries work just
fine (of course) on x86. Not so much on PPC --- I'm surprised it even
gets through initdb, but it does, and I was able to reproduce your
"expected just one rule action". The regression tests fail rather
miserably though.
Comparing the configure output files, it seems that Apple's compiler
uses the same alignment rules for x86 and ppc, so that the only actual
pg_config.h difference is WORDS_BIGENDIAN. Which means this probably
would have worked all right in pre-8.3 versions of PG. But the rules
for short datum headers in 8.3+ will not work at all if the machine
doesn't have the endianness the code thinks. It looks like the reason
for "expected just one rule action" is that most of the
pg_rewrite.ev_action entries read out as empty C strings --- they are
really text datums of more than 127 bytes and the tuple disaassembly
code is misinterpreting their length words. I suppose if your app
doesn't deal in fields that are wider than 127 bytes on-disk, you
might have managed to miss realizing that the build was entirely
busted...
So the bottom line seems to be that you need to modify your custom build
procedure to allow for architecture-specific pg_config.h.
regards, tom lane
