Israel Brewster <israel@xxxxxxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
