Fyi, this is exactly what i saw in my first attempts to build a universal binary. Running configure for each architecture and hacking up pg_config.h (per one of the archives links you posted previously) does fix it, though iirc, 32 & 64 bit builds in the same binary will take some more work. On 5/10/09, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Eric Smith <eric_h_smith@xxxxxxx> 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 > > -- > Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
