Universal libpq.a ?

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>