Thread: libpq.a in a universal binary

libpq.a in a universal binary

From
Ted Petrosky
Date:
I am trying to create the libpq.a as a universal binary (both ppc and  
intel macs). Does anyone have any information on this process?

Thanks,

Ted


Re: libpq.a in a universal binary

From
Dave Page
Date:
Ted Petrosky wrote:
> I am trying to create the libpq.a as a universal binary (both ppc and 
> intel macs). Does anyone have any information on this process?

I use the following notes to build libpq and the bin/ tools to ship with 
pgAdmin. I know it is possible to build the entire server, as a 
Universal binary, but I could never make it work and haven't had time to 
spend on it. Comments welcome :-)

======
Building the entire server as a Universal binary doesn't seem to work at
present, so, we build the backend as an architecture specific build,
then create libpq and the tools as Universal binaries over the top.

# ./configure --with-openssl --prefix=/usr/local/
# make all; make install

# 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

Note - this step will fail, but is required to complete the build of the 
tools.

# cd src/interface/libpq
# make all; make install
# cd ../../bin
# make all; make install
======

Regards, Dave


libpq.a in a universal binary

From
edwinoneel@acm.org
Date:
Hi,

The short summary that I use for .a files is:

Build on PPC
Build on Intel

On either run 

lipo -create lib/libpq.a ../ppc/lib/libpq.a ../intel/lib/libpq.a

Before a 

file libpq.a

shows

libpq.a: current ar archive

After lipo it shows:

libpq.a: Mach-O fat file with 2 architectures
libpq.a (for architecture ppc):        current ar archive
libpq.a (for architecture i386):       current ar archive random library


There is a nice Apple tech note on this

http://developer.apple.com/technotes/tn2005/tn2137.html

that talks about Universal Binaries.

It's possible that you might be able to do this all in one go since
the Apple compiler can support generating both intel and ppc output in
the same fat file.  But, if you can't, then the above technique works
just fine.

cheers

bruce


Ted Petrosky writes:> I am trying to create the libpq.a as a universal binary (both ppc and  > intel macs). Does anyone
haveany information on this process?> > Thanks,> > Ted> > ---------------------------(end of
broadcast)--------------------------->TIP 2: Don't 'kill -9' the postmaster
 

-- 
If brute force doesn't work, you're not using enough of it.

Bruce O'Neel                       phone:  +41 22 379 21 57
INTEGRAL Science Data Centre               +41 22 379 21 00 (switchb.)
Chemin d'Ecogia 16                 fax:    +41 22 379 21 35
CH-1290 VERSOIX                    e-mail: Bruce.Oneel@obs.unige.ch
Switzerland                        WWW:    http://isdc.unige.ch/



Re: libpq.a in a universal binary

From
Dave Page
Date:
Ted Petrosky wrote:
> Thanks for the reply.... at last nights cocoahead meeting in NYC I asked 
> and found a solution for libpq.a.
> 
> 1. config and make on a ppc
> 2. config and make on intel
> 
> copy and rename the libpq.a from each system to a common directory and 
> run 'lipo' on them:
> 
> lipo libpqppc.a libpqintel.a -output libpq.a
> 
> lipo will create the universal binary

Yeah - I looked at that option, but as I only have a G4 Powerbook at 
present I'd need to cross compile the intel version, and I couldn't get 
that to work at all!

The method I gave, while a little hacky, does work well and is pretty 
straightforward. It's also probably the only way that would be practical 
to build and install the whole tarball in a vaguely normal way (assuming 
there weren't other issues preventing the build completing).

Regards, Dave


Re: libpq.a in a universal binary

From
Ted Petrosky
Date:
Thanks for the reply.... at last nights cocoahead meeting in NYC I  
asked and found a solution for libpq.a.

1. config and make on a ppc
2. config and make on intel

copy and rename the libpq.a from each system to a common directory  
and run 'lipo' on them:

lipo libpqppc.a libpqintel.a -output libpq.a

lipo will create the universal binary

man lipo:

LIPO 
(1)                                                                 
LIPO(1)

NAME       lipo - create or operate on universal files

SYNOPSIS       lipo  [-info]  [-detailed_info]  [-arch  arch_type   
input_file]  ...  [       input_file] ...  [-arch_blank arch_type]  [-create]  [-thin   
arch_type]       [-replace  arch_type  filename] ...  [-remove arch_type] ...   
[-extract       arch_type] ...  [-extract_family arch_type] ...  [-output   
output_file]       [-segalign arch_type value] ...

DESCRIPTION       The  lipo command creates or operates on ``universal'' (multi- 
architec-       ture) files.  It only ever produces one output file, and   
never  alters       the  input  file.   The  operations that lipo performs are:  
listing the       architecture types in a universal file;  creating  a  single   
universal       file from one or more input files; thinning out a single  
universal file       to one specified architecture type; and extracting,   
replacing,  and/or       removing architectures types from the input file to create a  
single new       universal output file.

On Dec 13, 2006, at 3:33 AM, Dave Page wrote:

> Ted Petrosky wrote:
>> I am trying to create the libpq.a as a universal binary (both ppc  
>> and intel macs). Does anyone have any information on this process?
>
> I use the following notes to build libpq and the bin/ tools to ship  
> with pgAdmin. I know it is possible to build the entire server, as  
> a Universal binary, but I could never make it work and haven't had  
> time to spend on it. Comments welcome :-)
>
> ======
> Building the entire server as a Universal binary doesn't seem to  
> work at
> present, so, we build the backend as an architecture specific build,
> then create libpq and the tools as Universal binaries over the top.
>
> # ./configure --with-openssl --prefix=/usr/local/
> # make all; make install
>
> # 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
>
> Note - this step will fail, but is required to complete the build  
> of the tools.
>
> # cd src/interface/libpq
> # make all; make install
> # cd ../../bin
> # make all; make install
> ======
>
> Regards, Dave



Re: libpq.a in a universal binary

From
Dave Page
Date:
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).

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

Regards, Dave




Re: libpq.a in a universal binary

From
Shane Ambler
Date:
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


Re: libpq.a in a universal binary

From
Dave Page
Date:
Ted Petrosky wrote:
> take a look at this link....
> 
> http://www.entropy.ch/blog/Software/2006/02/04/PostgreSQL-Universal-Binary-Build-Tips.html 

I've seen links to there before, but it always times out for me. As it 
is now :-(

I've got your followup email though, so I'll try a build as soon a I can  - thanks!

Regards, Dave.


Re: libpq.a in a universal binary

From
Ted Petrosky
Date:
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