Re: libpq.a in a universal binary - Mailing list pgsql-hackers

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@007Marketing.com
>
> Get Sheeky @ http://Sheeky.Biz