Andrew Dunstan writes:
> On 3/26/20 11:31 AM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> I don't think this belongs in installcheck, we should add
>>> 'NO_INSTALLCHECK = 1' to the Makefile.
>> Why? The other src/test/modules/ modules with TAP tests do not
>> specify that, with the exception
On 3/26/20 11:31 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/26/20 9:50 AM, Tom Lane wrote:
>>> Why is jacana doing it differently?
>> longfin is also running it (first) here
>> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=longfin&dt=2020-03-26%2014%3A39%3A51&stg=ssl_pa
Andrew Dunstan writes:
> On 3/26/20 9:50 AM, Tom Lane wrote:
>> Why is jacana doing it differently?
> longfin is also running it (first) here
> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=longfin&dt=2020-03-26%2014%3A39%3A51&stg=ssl_passphrase_callback-check
Oh, I missed that.
On 3/26/20 9:50 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/25/20 9:28 PM, Tom Lane wrote:
>>> jacana has just exposed a different problem: it's not configured
>>> --with-openssl, but the buildfarm script is trying to run this
>>> new test module anyway. I'm confused about the reason.
Andrew Dunstan writes:
> On 3/25/20 9:28 PM, Tom Lane wrote:
>> jacana has just exposed a different problem: it's not configured
>> --with-openssl, but the buildfarm script is trying to run this
>> new test module anyway. I'm confused about the reason.
>> "make installcheck" in src/test/modules d
On 3/25/20 9:28 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/25/20 7:44 PM, Tom Lane wrote:
>>> I don't actually see why we need the localhost port at all --- it doesn't
>>> look like this test ever attempts to connect to the server. So couldn't
>>> we just drop that?
>> Seems reasonabl
Andrew Dunstan writes:
> On 3/25/20 7:44 PM, Tom Lane wrote:
>> I don't actually see why we need the localhost port at all --- it doesn't
>> look like this test ever attempts to connect to the server. So couldn't
>> we just drop that?
> Seems reasonable. I just tested that and it seems quite hap
On 3/25/20 7:44 PM, Tom Lane wrote:
> I wrote:
>> Concretely, I see that contrib/sslinfo has
>> SHLIB_LINK += $(filter -lssl -lcrypto -lssleay32 -leay32, $(LIBS))
> I verified that that fixes things on macOS and pushed it, along with
> a couple other minor fixes.
Thanks.
>
> However, I'm quit
I wrote:
> Concretely, I see that contrib/sslinfo has
> SHLIB_LINK += $(filter -lssl -lcrypto -lssleay32 -leay32, $(LIBS))
I verified that that fixes things on macOS and pushed it, along with
a couple other minor fixes.
However, I'm quite desperately unhappy that the new test module
does this:
$
I wrote:
> Buildfarm's not terribly happy --- I suspect that the makefile for
> the new test module is failing to link in libopenssl explicitly.
Concretely, I see that contrib/sslinfo has
SHLIB_LINK += $(filter -lssl -lcrypto -lssleay32 -leay32, $(LIBS))
which you probably need to crib here. Th
Andrew Dunstan writes:
> Provide a TLS init hook
Buildfarm's not terribly happy --- I suspect that the makefile for
the new test module is failing to link in libopenssl explicitly.
Some platforms are more forgiving of that than others.
regards, tom lane
Provide a TLS init hook
The default hook function sets the default password callback function.
In order to allow preloaded libraries to have an opportunity to override
the default, TLS initialization if now delayed slightly until after
shared preloaded libraries have been loaded.
A test module is
12 matches
Mail list logo
