Re: getting a list of users

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Eric Smith <eric_h_smith(at)mac(dot)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
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com