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(dot)coleman(at)gmail(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Doug Coleman <doug(dot)coleman(at)gmail(dot)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(dot)coleman(at)gmail(dot)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.