Обсуждение: Universal libpq.a ?
Hi, I am trying to bring one of my Cocoa based Postgresql browsers up to date. I would like to create a "universal", ie works on PPC and Intel Macintosh platforms, version of the application. I guess the initial task would be to build a universal version of libpq.a. In the past I have created simple universal (command line) apps by adding CFLAGS=-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc LDFLAGS=-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch ppc - arch i386 to the make file and adding an environmental variable MACOSX_DEPLOYMENT_TARGET=10.4 Has anyone built a universal libpq.a? Which make files should I target for modification? Thanks for any pointers :) Jerry
On Feb 4, 2008 3:35 PM, Jerry LeVan <jerry.levan@eku.edu> wrote: > Hi, > > I am trying to bring one of my Cocoa based Postgresql browsers > up to date. > > I would like to create a "universal", ie works on PPC and Intel > Macintosh > platforms, version of the application. > > I guess the initial task would be to build a universal version of > libpq.a. > > In the past I have created simple universal (command line) apps by > adding > > CFLAGS=-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc > LDFLAGS=-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch ppc - > arch i386 > > to the make file and adding an environmental variable > MACOSX_DEPLOYMENT_TARGET=10.4 > Has anyone built a universal libpq.a? > Which make files should I target for modification? > > Thanks for any pointers :) The Mac build of EDB Postgres is universal throughout, and 8.3.0 is available to download from today. Regards, Dave
"Dave Page" <dpage@postgresql.org> writes:
> The Mac build of EDB Postgres is universal throughout,
Yeah? How painful is it? We've had more than one request to enable
universal builds.
regards, tom lane
On Feb 4, 2008 6:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Dave Page" <dpage@postgresql.org> writes:
> > The Mac build of EDB Postgres is universal throughout,
>
> Yeah? How painful is it? We've had more than one request to enable
> universal builds.
There was fair bit of pain getting it to work, but the resulting
script isn't overly complex. Note this is based on work by the guys at
entropy.ch. Ignore the target directory fudging...
# Configure the source tree
echo "Configuring the Postgres source tree for Intel"
CFLAGS="-arch i386" LDFLAGS="-ltcl" MACOSX_DEPLOYMENT_TARGET=10.4
./configure --prefix=$INST_DIR --bindir=$INST_DIR/bin
--datadir=$INST_DIR/share --libdir=$INST_DIR/lib
--includedir=$INST_DIR/include --mandir=$INST_DIR/man --with-openssl
--with-perl --with-python --with-tcl --with-bonjour --with-pam
--with-krb5 --with-libxml || _die "Failed to configure Postgres for
i386"
mv src/include/pg_config.h src/include/pg_config_i386.h
echo "Configuring the Postgres source tree for PPC"
CFLAGS="-arch ppc" LDFLAGS="-ltcl" MACOSX_DEPLOYMENT_TARGET=10.4
./configure --prefix=$INST_DIR --bindir=$INST_DIR/bin
--datadir=$INST_DIR/share --libdir=$INST_DIR/lib
--includedir=$INST_DIR/include --mandir=$INST_DIR/man --with-openssl
--with-perl --with-python --with-tcl --with-bonjour --with-pam
--with-krb5 --with-libxml || _die "Failed to configure Postgres for
PPC"
mv src/include/pg_config.h src/include/pg_config_ppc.h
echo "Configuring the Postgres source tree for Universal"
CFLAGS="-arch ppc -arch i386" LDFLAGS="-ltcl"
MACOSX_DEPLOYMENT_TARGET=10.4 ./configure --prefix=$INST_DIR
--bindir=$INST_DIR/bin --datadir=$INST_DIR/share
--libdir=$INST_DIR/lib --includedir=$INST_DIR/include
--mandir=$INST_DIR/man --with-openssl --with-perl --with-python
--with-tcl --with-bonjour --with-pam --with-krb5 --with-libxml || _die
"Failed to configure Postgres for Universal"
# Create a replacement pg_config.h that will pull in the
appropriate architecture-specific one:
echo "#ifdef __BIG_ENDIAN__" > src/include/pg_config.h
echo "#include \"pg_config_ppc.h\"" >> src/include/pg_config.h
echo "#else" >> src/include/pg_config.h
echo "#include \"pg_config_i386.h\"" >> src/include/pg_config.h
echo "#endif" >> src/include/pg_config.h
# Fixup the makefiles
echo "Post-processing Makefiles for Universal Binary build"
find . -name Makefile -print -exec perl -p -i.backup -e 's/\Q$(LD)
$(LDREL) $(LDOUT)\E (\S+) (.+)/\$(LD) -arch ppc \$(LDREL) \$(LDOUT)
$1.ppc $2; \$(LD) -arch i386 \$(LDREL) \$(LDOUT) $1.i386 $2; lipo
-create -output $1 $1.ppc $1.i386/' {} \; || _die "Failed to
post-process the Postgres Makefiles for Universal build"
echo "Building Postgres"
MACOSX_DEPLOYMENT_TARGET=10.4 make -j 2 || _die "Failed to build Postgres"
make prefix=$STAGING bindir=$STAGING/bin datadir=$STAGING/share
libdir=$STAGING/lib includedir=$STAGING/include mandir=$STAGING/man
install || _die "Failed to install Postgres"
cp src/include/pg_config_i386.h $STAGING/include/
cp src/include/pg_config_ppc.h $STAGING/include/
echo "Building contrib modules"
cd contrib
MACOSX_DEPLOYMENT_TARGET=10.4 make || _die "Failed to build the
Postgres contrib modules"
make prefix=$STAGING bindir=$STAGING/bin datadir=$STAGING/share
libdir=$STAGING/lib includedir=$STAGING/include mandir=$STAGING/man
install || _die "Failed to install the Postgres contrib modules"
echo "Building xml2 module"
cd xml2
MACOSX_DEPLOYMENT_TARGET=10.4 make CFLAGS='-arch i386 -arch ppc'
|| _die "Failed to build the Postgres XML2 module"
make prefix=$STAGING bindir=$STAGING/bin datadir=$STAGING/share
libdir=$STAGING/lib includedir=$STAGING/include mandir=$STAGING/man
install || _die "Failed to install the Postgres XML2 module"
/D
On Feb 4, 2008, at 1:25 PM, Tom Lane wrote: > "Dave Page" <dpage@postgresql.org> writes: >> The Mac build of EDB Postgres is universal throughout, > > Yeah? How painful is it? We've had more than one request to enable > universal builds. > > regards, tom lane Here is a config file I tried mbp:postgresql-8.3.0 postgres$ more configJHLFat ./configure --bindir=/usr/local/bin --mandir=/usr/local/share/man \ --enable-thread-safety \ --enable-multibyte --with-perl --with-tcl \ --with-python --with-libedit-preferred \ --with-openssl --with-bonjour \ CFLAGS='-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc' \ LDFLAGS='-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch ppc - arch i386' \ LDFLAGS_SL='-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386' \ MACOSX_DEPLOYMENT_TARGET=10.4 I tried for a while to build the rascal and found the sticky point was invoking "ld". The man page for ld asserts that ld will only output a "thin" object file. In particular all of the SUBSYS.o files would default to plain old mach-o files. Eventually this caused problems during later linking. The man page for ld tantalized me by stating that gcc would automagically be enabled to build fat objects an invoke lipo to build a fat object. All of the *.o files generated by gcc where in fact fat object files. In fact I went to the interfaces directory and into the libpq subdirectory and invoked make and was able to build a "fat" libpq.a I was able to build an intel binary without any problems but it will be a couple of days before I find out if the "fat" libpq.a is actually functional ;( Jerry
"Dave Page" <dpage@postgresql.org> writes:
> On Feb 4, 2008 6:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> "Dave Page" <dpage@postgresql.org> writes:
>>> The Mac build of EDB Postgres is universal throughout,
>>
>> Yeah? How painful is it? We've had more than one request to enable
>> universal builds.
> There was fair bit of pain getting it to work, but the resulting
> script isn't overly complex. Note this is based on work by the guys at
> entropy.ch. Ignore the target directory fudging...
Hmm. The multiple versions of pg_config.h don't bother me --- the RPM
distributions have to do something very similar to support multilib
Linux platforms. This bit seems pretty brute-force though:
> # Fixup the makefiles
> echo "Post-processing Makefiles for Universal Binary build"
> find . -name Makefile -print -exec perl -p -i.backup -e 's/\Q$(LD)
> $(LDREL) $(LDOUT)\E (\S+) (.+)/\$(LD) -arch ppc \$(LDREL) \$(LDOUT)
> $1.ppc $2; \$(LD) -arch i386 \$(LDREL) \$(LDOUT) $1.i386 $2; lipo
> -create -output $1 $1.ppc $1.i386/' {} \; || _die "Failed to
> post-process the Postgres Makefiles for Universal build"
I thought I'd read that you could solve this problem by using the gcc
frontend to invoke loading, ie something involving making $(LD) call gcc
with some options. I'd be willing to tweak the LDxxx macros a bit if
needed to enable a solution like that, but changing the Makefiles at
build time is clearly right out ...
regards, tom lane
On Feb 5, 2008 1:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > # Fixup the makefiles
> > echo "Post-processing Makefiles for Universal Binary build"
> > find . -name Makefile -print -exec perl -p -i.backup -e 's/\Q$(LD)
> > $(LDREL) $(LDOUT)\E (\S+) (.+)/\$(LD) -arch ppc \$(LDREL) \$(LDOUT)
> > $1.ppc $2; \$(LD) -arch i386 \$(LDREL) \$(LDOUT) $1.i386 $2; lipo
> > -create -output $1 $1.ppc $1.i386/' {} \; || _die "Failed to
> > post-process the Postgres Makefiles for Universal build"
>
> I thought I'd read that you could solve this problem by using the gcc
> frontend to invoke loading, ie something involving making $(LD) call gcc
> with some options. I'd be willing to tweak the LDxxx macros a bit if
> needed to enable a solution like that, but changing the Makefiles at
> build time is clearly right out ...
My make-fu is not strong enough for that - which is why thats the bit
I nicked from the entropy.ch scripts!
Another option which may be doable for someone with more knowledge of
make would be to build binaries for all architectures seperately (you
can build i386, ppc, x86_64 and ppc64), and then use lipo to glue them
together.
/D
On Mon, 4 Feb 2008, Tom Lane wrote:
> "Dave Page" <dpage@postgresql.org> writes:
>> On Feb 4, 2008 6:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> "Dave Page" <dpage@postgresql.org> writes:
>>>> The Mac build of EDB Postgres is universal throughout,
>>>
>>> Yeah? How painful is it? We've had more than one request to enable
>>> universal builds.
>
>> There was fair bit of pain getting it to work, but the resulting
>> script isn't overly complex. Note this is based on work by the guys at
>> entropy.ch. Ignore the target directory fudging...
>
> Hmm. The multiple versions of pg_config.h don't bother me --- the RPM
> distributions have to do something very similar to support multilib
> Linux platforms. This bit seems pretty brute-force though:
>
>> # Fixup the makefiles
>> echo "Post-processing Makefiles for Universal Binary build"
>> find . -name Makefile -print -exec perl -p -i.backup -e 's/\Q$(LD)
>> $(LDREL) $(LDOUT)\E (\S+) (.+)/\$(LD) -arch ppc \$(LDREL) \$(LDOUT)
>> $1.ppc $2; \$(LD) -arch i386 \$(LDREL) \$(LDOUT) $1.i386 $2; lipo
>> -create -output $1 $1.ppc $1.i386/' {} \; || _die "Failed to
>> post-process the Postgres Makefiles for Universal build"
>
> I thought I'd read that you could solve this problem by using the gcc
> frontend to invoke loading, ie something involving making $(LD) call gcc
> with some options. I'd be willing to tweak the LDxxx macros a bit if
> needed to enable a solution like that, but changing the Makefiles at
> build time is clearly right out ...
When I was playing with this last week, the problem is that the gcc front end
when passing -Wl,-r still includes other things to make the relocatable SUBSYS.o's.
So, when we try to link, we get duplicate symbols.
I gave up, and just built it twice, and then lipo'd the 2 bin and lib directory
files together as a quick hack.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
On Tue, 5 Feb 2008, Dave Page wrote:
> On Feb 5, 2008 1:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> # Fixup the makefiles
>>> echo "Post-processing Makefiles for Universal Binary build"
>>> find . -name Makefile -print -exec perl -p -i.backup -e 's/\Q$(LD)
>>> $(LDREL) $(LDOUT)\E (\S+) (.+)/\$(LD) -arch ppc \$(LDREL) \$(LDOUT)
>>> $1.ppc $2; \$(LD) -arch i386 \$(LDREL) \$(LDOUT) $1.i386 $2; lipo
>>> -create -output $1 $1.ppc $1.i386/' {} \; || _die "Failed to
>>> post-process the Postgres Makefiles for Universal build"
>>
>> I thought I'd read that you could solve this problem by using the gcc
>> frontend to invoke loading, ie something involving making $(LD) call gcc
>> with some options. I'd be willing to tweak the LDxxx macros a bit if
>> needed to enable a solution like that, but changing the Makefiles at
>> build time is clearly right out ...
>
> My make-fu is not strong enough for that - which is why thats the bit
> I nicked from the entropy.ch scripts!
>
> Another option which may be doable for someone with more knowledge of
> make would be to build binaries for all architectures seperately (you
> can build i386, ppc, x86_64 and ppc64), and then use lipo to glue them
> together.
I did essentially that, outside of make, for ppc/i386 doing 2 separate builds
and then using lipo to join each file in bin and lib.
LER
>
> /D
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
Larry Rosenman wrote: > On Tue, 5 Feb 2008, Dave Page wrote: >> Another option which may be doable for someone with more knowledge of >> make would be to build binaries for all architectures seperately (you >> can build i386, ppc, x86_64 and ppc64), and then use lipo to glue them >> together. > I did essentially that, outside of make, for ppc/i386 doing 2 separate builds > and then using lipo to join each file in bin and lib. Sure looks like this should be doable with only Makefile rules. I very much doubt it would be painless, though. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Feb 5, 2008 3:07 PM, Larry Rosenman <ler@lerctr.org> wrote: > > On Tue, 5 Feb 2008, Dave Page wrote: > > > Another option which may be doable for someone with more knowledge of > > make would be to build binaries for all architectures seperately (you > > can build i386, ppc, x86_64 and ppc64), and then use lipo to glue them > > together. > I did essentially that, outside of make, for ppc/i386 doing 2 separate builds > and then using lipo to join each file in bin and lib. Yeah, but can you wrap it all up into a patch to the build system that Tom would approve of? :) /D
On Tue, 5 Feb 2008, Dave Page wrote: > On Feb 5, 2008 3:07 PM, Larry Rosenman <ler@lerctr.org> wrote: >> >> On Tue, 5 Feb 2008, Dave Page wrote: >> >>> Another option which may be doable for someone with more knowledge of >>> make would be to build binaries for all architectures seperately (you >>> can build i386, ppc, x86_64 and ppc64), and then use lipo to glue them >>> together. > >> I did essentially that, outside of make, for ppc/i386 doing 2 separate builds >> and then using lipo to join each file in bin and lib. > > Yeah, but can you wrap it all up into a patch to the build system that > Tom would approve of? :) > I knew that was coming, and it's on my list :) > /D > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
Em Tuesday 05 February 2008 13:27:08 Larry Rosenman escreveu: > On Tue, 5 Feb 2008, Dave Page wrote: > > > > Yeah, but can you wrap it all up into a patch to the build system that > > Tom would approve of? :) > > I knew that was coming, and it's on my list :) The hardest part: "that Tom would approve" :-) -- Jorge Godoy <jgodoy@gmail.com>