Обсуждение: macports and brew postgresql --universal builds
The MacPorts Project (http://www.macports.org/) supports building universal binaries (32/64bit binaries in one file) for most projects. For PostgreSQL, they apply two patches after the configure script to correct some of the typedefs. Otherwise, the build fails in compiling a switch statement with duplicate cases. The HomeBrew Project (http://mxcl.github.com/homebrew/) is a worthy successor to MacPorts, but they don't yet support a --universal argument for building PostgreSQL. There is currently a pull request on github to add universal support, but it's based on the patches from the MacPorts project. It would be nice if the PostgreSQL project would make these patches unnecessary. A diff of the HomeBrew pull request to add universal support: https://github.com/mxcl/homebrew/pull/14111/files The patches in question: https://trac.macports.org/export/96361/trunk/dports/databases/postgresql91/files/pg_config.h.ed https://trac.macports.org/export/96361/trunk/dports/databases/postgresql91/files/ecpg_config.h.ed If someone were to fix this, to test if the fix worked you would need a Mac with HomeBrew, the HomeBrew pull request above but without lines 70-74, and this command: brew install postgresql --universal Note that if you previously had postgresql installed with HomeBrew, you would need to uninstall it first. Cheers, Doug
Doug Coleman <doug.coleman@gmail.com> writes: > The MacPorts Project (http://www.macports.org/) supports building > universal binaries (32/64bit binaries in one file) for most projects. > For PostgreSQL, they apply two patches after the configure script to > correct some of the typedefs. Otherwise, the build fails in compiling > a switch statement with duplicate cases. > The HomeBrew Project (http://mxcl.github.com/homebrew/) is a worthy > successor to MacPorts, but they don't yet support a --universal > argument for building PostgreSQL. There is currently a pull request on > github to add universal support, but it's based on the patches from > the MacPorts project. The files you link to don't make much sense to me (they do not look like patch diffs) but they seem to suggest hard-wiring configure results into the source code, which does not sound like an acceptable solution from our standpoint. The approach we've suggested to people in the past is running configure for each architecture and then building against that copy of pg_config.h, or more likely combining the .h files with arch-specific #ifdefs. You can find more info in our list archives --- the most relevant thread I could find easily starts here: http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php regards, tom lane
On Fri, Aug 10, 2012 at 3:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > The files you link to don't make much sense to me (they do not look > like patch diffs) but they seem to suggest hard-wiring configure results > into the source code, which does not sound like an acceptable solution > from our standpoint. I've also never seen this format before, which are...ed expressions. I guess that makes them less sensitive to line churn. Cute, but...wow. -- fdr
What it looks like is the first line of each section is pattern matching. If __LP64__ is defined, then it's a 64-bit architecture, and we want to use the top part of the if statement. The #defines they target seem to be all of the ones that are different on 32bit platforms. I agree that you would want to do this in the configure script somehow. Doug On Fri, Aug 10, 2012 at 3:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Doug Coleman <doug.coleman@gmail.com> writes: >> The MacPorts Project (http://www.macports.org/) supports building >> universal binaries (32/64bit binaries in one file) for most projects. >> For PostgreSQL, they apply two patches after the configure script to >> correct some of the typedefs. Otherwise, the build fails in compiling >> a switch statement with duplicate cases. > >> The HomeBrew Project (http://mxcl.github.com/homebrew/) is a worthy >> successor to MacPorts, but they don't yet support a --universal >> argument for building PostgreSQL. There is currently a pull request on >> github to add universal support, but it's based on the patches from >> the MacPorts project. > > The files you link to don't make much sense to me (they do not look > like patch diffs) but they seem to suggest hard-wiring configure results > into the source code, which does not sound like an acceptable solution > from our standpoint. > > The approach we've suggested to people in the past is running configure > for each architecture and then building against that copy of > pg_config.h, or more likely combining the .h files with arch-specific > #ifdefs. You can find more info in our list archives --- the most > relevant thread I could find easily starts here: > http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php > > regards, tom lane
On 08/10/2012 06:44 PM, Tom Lane wrote: > Doug Coleman <doug.coleman@gmail.com> writes: >> The MacPorts Project (http://www.macports.org/) supports building >> universal binaries (32/64bit binaries in one file) for most projects. >> For PostgreSQL, they apply two patches after the configure script to >> correct some of the typedefs. Otherwise, the build fails in compiling >> a switch statement with duplicate cases. >> The HomeBrew Project (http://mxcl.github.com/homebrew/) is a worthy >> successor to MacPorts, but they don't yet support a --universal >> argument for building PostgreSQL. There is currently a pull request on >> github to add universal support, but it's based on the patches from >> the MacPorts project. > The files you link to don't make much sense to me (they do not look > like patch diffs) OMG, I think they are ed scripts, possibly produced using "diff -e". I'm having flashbacks to when I used such stuff twenty or so years ago. cheers andrew
On 8/10/12 7:12 PM, Doug Coleman wrote: > What it looks like is the first line of each section is pattern matching. > > If __LP64__ is defined, then it's a 64-bit architecture, and we want > to use the top part of the if statement. The #defines they target seem > to be all of the ones that are different on 32bit platforms. > > I agree that you would want to do this in the configure script somehow. That's not going to work. The configure script can only test one target at a time. You can probably get away with it on many simple programs, but when a configure script checks size and alignment of types, the whole concept of universal builds is at odds with the approach Autoconf takes. OK, so you get away with it by patching up a few sites, but you're effectively overriding the configure checks with hardcoded results. I think the only sane approach in general is to build the entire project twice and merge the resulting binaries together.