Re: More Snow Leopard fun: multiarch problems while building plperl
От | Jan Otto |
---|---|
Тема | Re: More Snow Leopard fun: multiarch problems while building plperl |
Дата | |
Msg-id | EF728623-4C62-411A-9EA9-1F5268A8F4CA@me.com обсуждение исходный текст |
Ответ на | Re: More Snow Leopard fun: multiarch problems while building plperl (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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. > > 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
В списке pgsql-hackers по дате отправления: