Re: libpq.a in a universal binary

Dave Page wrote:
> Shane Ambler wrote:
>>
>>>> # make distclean
>>>> # CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch
>>>> i386" LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch
>>>> ppc
>>>> -arch i386" ./configure --with-openssl --prefix=/usr/local
>>>> # make all
>>
>> After reading the Apple tech doc on this
>> http://developer.apple.com/technotes/tn2005/tn2137.html
>> I am wondering if we can add Mac universal binary support to the TODO
>> list.
>>
>> I haven't tested this yet but from what I gather adding the
>> --disable-dependency-tracking option to configure will allow the
>> option of setting the CFLAGS and LDFLAGS with "-arch ppc -arch i386"
>> and getting the universal binary build.
>
> The PostgreSQL build doesn't use the dependency tracking (at least not
> by default) so that's not an issue. pgAdmin does on the other hand, and
> the build will fail loudly if you don't disable tracking when you
> configure.
>
>> Another possibility (the better option) would be to add an option to
>> build universal binaries - such as --host=mac_universal or would that
>> be --host=darwin_universal - to automate the CFLAGS and LDFLAGS
>> settings. Adding --with-isysroot= should be added to support
>> non-standard and future SDK setups as well.
>
> In pgAdmin we figure out what to build for based on the wxWidgets
> installation. In PostgreSQL's case, I would imagine we'd need to list
> the architectures to include in the build per the example above however
> it was automated (you might want ppc and ppc64 but not intel for example).

You could have a few options -
--host=darwin-ppc-i386
--host=darwin-ppc-ppc64-i386-amd64
etc.

maybe this could be better setup by splitting the string after darwin_
instead of having many different single hosts as such.

If host starts with "darwin" and len(host)>6
arch_string() = explode("-",ltrim(host,7))
CFLAGS=CFLAGS+" -arch "+arch_string(x)
else
build for current cpu

Maybe the --host= options with all the different possibilities won't be
taken in, but I think a TODO should at least be added (not a high
priority) to support building universal binaries even if only fixing the
current failure point so that one make command can be used to get the
end product even if it is a partly manual configure.
And this would apply to the client libs more than the server itself.

> FWIW, from memory the PostgreSQL build fails at the point at which it
> links all the SUBSYS.o's.
>

Actually now that I checked it on a clean source tree (8.2.0) and not a
make/make clean'd source tree it does appear to get to the SUBSYS.o's
(when I make clean then set CFLAGS etc it stopped at the beginning)

As I said I hadn't looked into it much and my first impression of trying
this gave me misleading thoughts of what was needed.

--

Shane Ambler
pgSQL(at)007Marketing(dot)com

Get Sheeky @ http://Sheeky.Biz