From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, buildfarm(at)sraoss(dot)co(dot)jp |
Subject: | Re: Missing include <openssl/x509.h> in be-secure-openssl.c? |
Date: | 2021-11-01 13:33:35 |
Message-ID: | 1129759.1635773615@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> It does make sense, but it's a bit worrisome that the indirect inclusion no
> longer works as there is no obvious explanation as to why.
Yeah. Just to make things even more confusing, hamerkop is not failing
in the back branches. v14 at least has exactly the same contents of
be-secure-openssl.c, so how's that happening?
>> x509v3.h includes x509.h, so fe-secure-openssl.h would not need an
>> update. Now could it be a better practice to include both there?
> Judging by OpenSSL, including both is common practice unless the module only
> deals with v3 extensions. Following that lead seems reasonable.
I see that fe-secure-openssl.c includes only x509v3.h, and it builds
successfully on hamerkop. So I'm now inclined to make be-secure-openssl.c
match that. But it'd still be a good thing to trace the real cause.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2021-11-01 13:38:11 | Commitfest 2021-11 |
Previous Message | osumi.takamichi@fujitsu.com | 2021-11-01 13:18:18 | RE: Failed transaction statistics to measure the logical replication progress |