Re: libpq.a in a universal binary

take a look at this link....

http://www.entropy.ch/blog/Software/2006/02/04/PostgreSQL-Universal-
Binary-Build-Tips.html

does this help?

Ted

On Dec 14, 2006, at 2:37 PM, Shane Ambler wrote:

> 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