Re: configure fails for perl check on CentOS8

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: configure fails for perl check on CentOS8
Date: 2019-10-20 23:36:39
Message-ID: 2990.1571614599@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
> On 10/20/19 1:23 PM, Tom Lane wrote:
>> The right way to fix it, likely, is to add CFLAGS_SL while performing this
>> particular autoconf test, as that would replicate the switches used for
>> plperl (and it turns out that adding -fPIC does solve this problem).
>> But the configure script doesn't currently know about CFLAGS_SL, so we'd
>> have to do some refactoring to approach it that way. Moving that logic
>> from the platform-specific Makefiles into configure doesn't seem
>> unreasonable, but it would make the patch bigger.

> Sounds like a plan. I agree it's annoying to have to do something large
> for something so trivial.

Turns out it's not really that bad. We just have to transfer the
responsibility for setting CFLAGS_SL from the platform Makefiles
to the platform template files. (As a bonus, it'd be possible to
allow users to override CFLAGS_SL during configure, as they can
do for CFLAGS. But I didn't mess with that here.)

I checked that this fixes the Fedora build problem, but I've not
really tested it on any other platform. Still, there's not that
much to go wrong, one would think.

regards, tom lane

Attachment Content-Type Size
0001-rearrange-CFLAGS_SL-generation.patch text/x-diff 9.2 KB
0002-fix-libperl-probe.patch text/x-diff 1.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2019-10-21 00:37:26 Re: [HACKERS] Block level parallel vacuum
Previous Message raf 2019-10-20 23:31:15 Re: jsonb_set() strictness considered harmful to data