>> 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
