Israel Brewster <israel@frontierflying.com> writes:
> So what it boils down to, if I now understand you correctly, is that
> (since you obviously can only have one set of headers per build) the
> only way to make this work is pretty much exactly what I ended up
> doing: build for each architecture separately (even if on the same
> machine) and then lipo the results together. I can live with that.
You can, but you don't have to. The alternative is to generate the
machine-specific headers, set them up to be pulled in with #ifdefs,
and then do one compile run with multiple -arch switches. This does
not work for pre-8.4 PG sources but does with 8.4. The one post
I pointed you to shows a script for setting up the headers that way.
(It also talks about using lipo because it predated 8.4, but you
can skip that part of the recipe.)
> Then the reason this is necessary on Postgres, and not with other
> software I have dealt with is that Postgres has 64 bit specific code,
> while the others don't?
The others are just accidentally failing to fail at the build stage.
I'm still pretty suspicious about whether the executables actually
work on arches other than where you built. I am one hundred percent
certain that MySQL has arch-dependent headers just like we do (because
I have to cope with them when I build Red Hat's mysql packages). It's
possible that SQLite manages to avoid generating any arch-specific
source code during its build process, but I rather doubt it.
Given that you only care about client libraries and not servers, it
might be that the breakage doesn't really affect you --- the server
side is much more likely to need the sort of tricks that lead to
generating arch-dependent headers. But I wouldn't trust them an
inch unless I'd tested them pretty thoroughly. It would be much
safer to build with correct headers.
>> I don't really recall whether I hit this in the experiment I did
>> last year. It's possible, maybe even likely, that the code was
>> different then and happened not to have any compiler-visible
>> inconsistencies when the header was wrong for the target arch.
> Or perhaps the 10.6 compiler has better error checking than the 10.5?
Actually, I think I know what the difference is: 10.5 didn't have any
support for x86_64 did it? If configure was generating declarations for
32-bit, at least the one particular bit of code we looked at would have
compiled happily on either word size --- and then failed at runtime on
64-bit because it was missing a needed case branch. But again, I think
that's server-only code.
regards, tom lane
