Thread: More Snow Leopard fun: multiarch problems while building plperl
Building plperl in CVS HEAD, the link step looks like this:
gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
-fno-strict-aliasing-fwrapv -g -bundle -multiply_defined suppress plperl.o spi_internal.o SPI.o -bundle_loader
../../../src/backend/postgres-L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-thread-multi-2level/CORE
-L../../../src/port-arch x86_64 -arch i386 -arch ppc -lperl -ldl -lm -lutil -lc -o plperl.so
and complains like this:
ld: warning: in ../../../src/backend/postgres, file is not of required architecture
ld: warning: in plperl.o, file is not of required architecture
ld: warning: in spi_internal.o, file is not of required architecture
ld: warning: in SPI.o, file is not of required architecture
ld: warning: in ../../../src/backend/postgres, file is not of required architecture
ld: warning: in plperl.o, file is not of required architecture
ld: warning: in spi_internal.o, file is not of required architecture
ld: warning: in SPI.o, file is not of required architecture
libperl.so, like much of the rest of the system, seems to be a
3-architecture universal binary:
$ file /System/Library/Perl/lib/5.10/libperl.dylib
/System/Library/Perl/lib/5.10/libperl.dylib: Mach-O universal binary with 3 architectures
/System/Library/Perl/lib/5.10/libperl.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library
x86_64
/System/Library/Perl/lib/5.10/libperl.dylib (for architecture i386): Mach-O dynamically linked shared library i386
/System/Library/Perl/lib/5.10/libperl.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc
which I found rather surprising because I thought Snow Leopard had
yanked out all support for PPC. However, there it is. But you do *not*
get 3-arch binaries out of gcc by default, and thus the warnings.
The reason the linker is complaining is that it was asked to produce
a 3-arch binary by the "-arch x86_64 -arch i386 -arch ppc" switches.
It did:
$ file plperl.so
plperl.so: Mach-O universal binary with 3 architectures
plperl.so (for architecture x86_64): Mach-O 64-bit bundle x86_64
plperl.so (for architecture i386): Mach-O bundle i386
plperl.so (for architecture ppc): Mach-O bundle ppc
but I'll bet a lot of money the other two arches don't actually work.
Anyway, the long and the short of it is that we are extracting this
value for perl_embed_ldflags:
perl_embed_ldflags = -arch x86_64 -arch i386 -arch ppc -L/usr/local/lib
-L/System/Library/Perl/5.10.0/darwin-thread-multi-2level/CORE-lperl -ldl -lm -lutil -lc
and it seems to me that it's a pretty bad idea to have this switch
collection trying to override the arch(es) that Postgres is actually
being built for. Does anyone have an opinion about that pro or con?
Anybody have an idea about a simple way to get rid of those switches?
regards, tom lane
On mån, 2009-09-07 at 23:13 -0400, Tom Lane wrote:
> Anyway, the long and the short of it is that we are extracting this
> value for perl_embed_ldflags:
>
> perl_embed_ldflags = -arch x86_64 -arch i386 -arch ppc
> -L/usr/local/lib
> -L/System/Library/Perl/5.10.0/darwin-thread-multi-2level/CORE -lperl
> -ldl -lm -lutil -lc
>
> and it seems to me that it's a pretty bad idea to have this switch
> collection trying to override the arch(es) that Postgres is actually
> being built for. Does anyone have an opinion about that pro or con?
> Anybody have an idea about a simple way to get rid of those switches?
perl_embed_ldflags is currently the difference of
perl -MExtUtils::Embed -e ldopts
minus
perl -MConfig -e 'print $Config{ccdlflags}'
In that spirit, the answer would be to find something else in ExtUtils
or Config that we can remove from ldopts.
The list of all candidates can be obtained by
perl -e 'use Config qw(config_sh); print config_sh;'
hi tom, > Anyway, the long and the short of it is that we are extracting this > value for perl_embed_ldflags: > > perl_embed_ldflags = -arch x86_64 -arch i386 -arch ppc -L/usr/ > local/lib -L/System/Library/Perl/5.10.0/darwin-thread-multi-2level/ > CORE -lperl -ldl -lm -lutil -lc > > and it seems to me that it's a pretty bad idea to have this switch > collection trying to override the arch(es) that Postgres is actually > being built for. Does anyone have an opinion about that pro or con? > Anybody have an idea about a simple way to get rid of those switches? patch for file configure: 6811c6811 < perl_embed_ldflags=`echo X"$pgac_tmp1" | sed "s/^X//;s%$pgac_tmp2%%"` ---> perl_embed_ldflags=`echo X"$pgac_tmp1" | sed "s/^X//;s%$pgac_tmp2% %" | sed "s/-arch\ [a-zA-Z0-9_-]*//g"` $ configure --with-perl $ make -j8>build.log $ file src/pl/plperl/plperl.so src/pl/plperl/plperl.so: Mach-O 64-bit bundle x86_64 $ regards, jan otto
hi tom, > $ file /System/Library/Perl/lib/5.10/libperl.dylib > /System/Library/Perl/lib/5.10/libperl.dylib: Mach-O universal binary > with 3 architectures > /System/Library/Perl/lib/5.10/libperl.dylib (for architecture > x86_64): Mach-O 64-bit dynamically linked shared library x86_64 > /System/Library/Perl/lib/5.10/libperl.dylib (for architecture > i386): Mach-O dynamically linked shared library i386 > /System/Library/Perl/lib/5.10/libperl.dylib (for architecture > ppc7400): Mach-O dynamically linked shared library ppc > > which I found rather surprising because I thought Snow Leopard had > yanked out all support for PPC. However, there it is. But you do > *not* these universal libraries are needed for older programs to run. you can run programs with ppc-architecture on snow leopard. and you probably need it if you cross-compile for a ppc-machine. > $ file plperl.so > plperl.so: Mach-O universal binary with 3 architectures > plperl.so (for architecture x86_64): Mach-O 64-bit bundle x86_64 > plperl.so (for architecture i386): Mach-O bundle i386 > plperl.so (for architecture ppc): Mach-O bundle ppc another way is to extract the needed architectures after the build. e.g. for x86_64: ditto --rsrc --arch x86_64 libperl.so libperl.so.tmp && mv libperl.so.tmp libperl.so regards, jan otto
Peter Eisentraut <peter_e@gmx.net> writes:
> On mån, 2009-09-07 at 23:13 -0400, Tom Lane wrote:
>> ... it seems to me that it's a pretty bad idea to have this switch
>> collection trying to override the arch(es) that Postgres is actually
>> being built for. Does anyone have an opinion about that pro or con?
>> Anybody have an idea about a simple way to get rid of those switches?
> perl_embed_ldflags is currently the difference of
> perl -MExtUtils::Embed -e ldopts
> minus
> perl -MConfig -e 'print $Config{ccdlflags}'
> In that spirit, the answer would be to find something else in ExtUtils
> or Config that we can remove from ldopts.
As far as I can tell, there is nothing in Config that exposes just the
-arch switches without any other stuff. I'm inclined to go with Jan
Otto's solution of sed'ing out those switches by name. It's a bit ugly
but should be safe.
BTW, I realized that the same problem exists already on OS X 10.5;
you can see it in buildfarm member korat's results, for instance.
10.5 seems to just use "-arch ppc -arch i386", but that's still more
than you want if you're not building PG as a universal binary.
regards, tom lane
hi tom,
>> perl_embed_ldflags is currently the difference of
>> perl -MExtUtils::Embed -e ldopts
>> minus
>> perl -MConfig -e 'print $Config{ccdlflags}'
>> In that spirit, the answer would be to find something else in
>> ExtUtils
>> or Config that we can remove from ldopts.
>
> As far as I can tell, there is nothing in Config that exposes just the
> -arch switches without any other stuff. I'm inclined to go with Jan
> Otto's solution of sed'ing out those switches by name. It's a bit
> ugly
> but should be safe.
Yes it is really ugly.
The problem here is that ARCHFLAGS is not set. If it is set correctly
the ldopts would be correctly set:
$ export ARCHFLAGS="-arch x86_64"
$ perl -MExtUtils::Embed -e ldopts -arch x86_64 -L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-
thread-multi-2level/CORE -lperl -ldl -lm -lutil -lc
$
if ARCHFLAGS is not set Config_heavy.pl puts '-arch x86_64 -arch i386 -
arch ppc' in by default:
$ unset ARCHFLAGS
$ perl -MExtUtils::Embed -e ldopts -L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-thread-
multi-2level/CORE -lperl -ldl -lm -lutil -lc
$
more elegant would be something like this instead of 'perl -
MExtUtils::Embed -e ldopts'
[ "$ARCHFLAGS" ] || export ARCHFLAGS=""; perl -MExtUtils::Embed -e
ldopts
example:
$ export ARCHFLAGS="-arch x86_64"
$ [ "$ARCHFLAGS" ] || export ARCHFLAGS=""; perl -MExtUtils::Embed -e
ldopts -arch x86_64 -L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-
thread-multi-2level/CORE -lperl -ldl -lm -lutil -lc
$ unset ARCHFLAGS
$ [ "$ARCHFLAGS" ] || export ARCHFLAGS=""; perl -MExtUtils::Embed -e
ldopts -L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-thread-
multi-2level/CORE -lperl -ldl -lm -lutil -lc
$
so we make shure if somebody tries to build an universal binary of
postgres by setting the correct ARCHFLAGS
the configure works too.
patch against HEAD:
diff -c -r1.653 configure
*** configure 26 Aug 2009 22:24:41 -0000 1.653
--- configure 8 Sep 2009 17:47:29 -0000
***************
*** 6941,6947 ****
{ $as_echo "$as_me:$LINENO: checking for flags to link embedded
Perl" >&5 $as_echo_n "checking for flags to link embedded Perl... " >&6; }
! pgac_tmp1=`$PERL -MExtUtils::Embed -e ldopts` pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'`
perl_embed_ldflags=`echoX"$pgac_tmp1" | sed "s/^X//;s%$pgac_tmp2%%"` if test -z "$perl_embed_ldflags" ; then
--- 6941,6947 ----
{ $as_echo "$as_me:$LINENO: checking for flags to link embedded
Perl" >&5 $as_echo_n "checking for flags to link embedded Perl... " >&6; }
! pgac_tmp1=`[ "$ARCHFLAGS" ] || export ARCHFLAGS=""; $PERL -
MExtUtils::Embed -e ldopts` pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'` perl_embed_ldflags=`echo
X"$pgac_tmp1"| sed "s/^X//;s%$pgac_tmp2%%"` if test -z "$perl_embed_ldflags" ; then
regards, jan otto
> The problem here is that ARCHFLAGS is not set. If it is set correctly
> the ldopts would be correctly set:
>
> $ export ARCHFLAGS="-arch x86_64"
> $ perl -MExtUtils::Embed -e ldopts
> -arch x86_64 -L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-
> thread-multi-2level/CORE -lperl -ldl -lm -lutil -lc
> $
>
> if ARCHFLAGS is not set Config_heavy.pl puts '-arch x86_64 -arch
> i386 -arch ppc' in by default:
>
> $ unset ARCHFLAGS
> $ perl -MExtUtils::Embed -e ldopts
> -L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-thread-
> multi-2level/CORE -lperl -ldl -lm -lutil -lc
> $
sorry wrong pasted:
$ unset ARCHFLAGS
$ perl -MExtUtils::Embed -e ldopts -arch x86_64 -arch i386 -arch ppc -L/usr/local/lib -L/System/
Library/Perl/5.10.0/darwin-thread-multi-2level/CORE -lperl -ldl -lm -
lutil -lc
$
>
> more elegant would be something like this instead of 'perl -
> MExtUtils::Embed -e ldopts'
>
> [ "$ARCHFLAGS" ] || export ARCHFLAGS=""; perl -MExtUtils::Embed -e
> ldopts
>
> example:
> $ export ARCHFLAGS="-arch x86_64"
> $ [ "$ARCHFLAGS" ] || export ARCHFLAGS=""; perl -MExtUtils::Embed -e
> ldopts
> -arch x86_64 -L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-
> thread-multi-2level/CORE -lperl -ldl -lm -lutil -lc
> $ unset ARCHFLAGS
> $ [ "$ARCHFLAGS" ] || export ARCHFLAGS=""; perl -MExtUtils::Embed -e
> ldopts
> -L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-thread-
> multi-2level/CORE -lperl -ldl -lm -lutil -lc
> $
>
> so we make shure if somebody tries to build an universal binary of
> postgres by setting the correct ARCHFLAGS
> the configure works too.
>
> patch against HEAD:
>
> diff -c -r1.653 configure
> *** configure 26 Aug 2009 22:24:41 -0000 1.653
> --- configure 8 Sep 2009 17:47:29 -0000
> ***************
> *** 6941,6947 ****
>
> { $as_echo "$as_me:$LINENO: checking for flags to link embedded
> Perl" >&5
> $as_echo_n "checking for flags to link embedded Perl... " >&6; }
> ! pgac_tmp1=`$PERL -MExtUtils::Embed -e ldopts`
> pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'`
> perl_embed_ldflags=`echo X"$pgac_tmp1" | sed "s/^X//;s%$pgac_tmp2%%"`
> if test -z "$perl_embed_ldflags" ; then
> --- 6941,6947 ----
>
> { $as_echo "$as_me:$LINENO: checking for flags to link embedded
> Perl" >&5
> $as_echo_n "checking for flags to link embedded Perl... " >&6; }
> ! pgac_tmp1=`[ "$ARCHFLAGS" ] || export ARCHFLAGS=""; $PERL -
> MExtUtils::Embed -e ldopts`
> pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'`
> perl_embed_ldflags=`echo X"$pgac_tmp1" | sed "s/^X//;s%$pgac_tmp2%%"`
> if test -z "$perl_embed_ldflags" ; then
>
> regards, jan otto
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
Ups, my previous patch was already applied in HEAD. This patch removes
the sed-patch
and added the check and set of ARCHFLAGS.
diff -c -r1.655 configure
*** configure 8 Sep 2009 18:15:55 -0000 1.655
--- configure 8 Sep 2009 18:30:04 -0000
***************
*** 6941,6949 ****
{ $as_echo "$as_me:$LINENO: checking for flags to link embedded
Perl" >&5 $as_echo_n "checking for flags to link embedded Perl... " >&6; }
! pgac_tmp1=`$PERL -MExtUtils::Embed -e ldopts` pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'`
! perl_embed_ldflags=`echo X"$pgac_tmp1" | sed -e "s/^X//" -e "s%
$pgac_tmp2%%" -e "s/ -arch [-a-zA-Z0-9_]*//g"` if test -z "$perl_embed_ldflags" ; then { $as_echo
"$as_me:$LINENO:result: no" >&5 $as_echo "no" >&6; }
--- 6941,6949 ----
{ $as_echo "$as_me:$LINENO: checking for flags to link embedded
Perl" >&5 $as_echo_n "checking for flags to link embedded Perl... " >&6; }
! pgac_tmp1=`[ "$ARCHFLAGS" ] || export ARCHFLAGS=""; $PERL -
MExtUtils::Embed -e ldopts` pgac_tmp2=`$PERL -MConfig -e 'print $Config{ccdlflags}'`
! perl_embed_ldflags=`echo X"$pgac_tmp1" | sed -e "s/^X//" -e "s%
$pgac_tmp2%%"` if test -z "$perl_embed_ldflags" ; then { $as_echo "$as_me:$LINENO: result: no" >&5 $as_echo
"no">&6; }
regards, jan otto
Jan Otto <asche@me.com> writes: > Ups, my previous patch was already applied in HEAD. This patch removes > the sed-patch and added the check and set of ARCHFLAGS. This seems to be assuming a lot more about the behavior of Apple's Perl hacks than I think we should. The patch as committed is good, because having any -arch flags in $perl_embed_ldflags is flat out wrong no matter what. They need to be in some other variable such as CFLAGS in order to have the desired effect. If you're proposing that the whole Postgres build system start paying attention to ARCHFLAGS instead of/in addition to CFLAGS, we could talk about that, but it'll be a much larger patch. See also the thread here http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php which points out that propagating -arch is the least of our worries. regards, tom lane
>> Ups, my previous patch was already applied in HEAD. This patch >> removes >> the sed-patch and added the check and set of ARCHFLAGS. > > This seems to be assuming a lot more about the behavior of Apple's > Perl > hacks than I think we should. The patch as committed is good, because > having any -arch flags in $perl_embed_ldflags is flat out wrong no > matter what. They need to be in some other variable such as CFLAGS > in order to have the desired effect. Of course. I meant only that Config_heavy.pl (required by Config.pm) depends on correctly setup of ARCHFLAGS. > If you're proposing that the whole Postgres build system start paying > attention to ARCHFLAGS instead of/in addition to CFLAGS, we could talk > about that, but it'll be a much larger patch. See also the thread > here If you dont want the linker warnings about libperl.dylib has not the required architecture and getting the ldopts with 'perl -MExtUtils::Embed -e ldopts' then you have to specify the correct arch-flags in ARCHFLAGS to get the correct ldopts (or strip out the '-arch xxx' from that output). I think that plperl in postgres build system is the only place where ARCHFLAGS is needed. i am not aware of other places. for me these linker warnings are not a real problem, because i know the reason for that and it is not affecting me or my work. > http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php > which points out that propagating -arch is the least of our worries. i will take a look. regards, jan otto