> On 1 Nov 2021, at 14:33, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.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?
That to me has the smell of some form of environment tainting or pollution, as
opposed to a code problem. v14 and HEAD are identical wrt to building this, so
the answer is likely to lie elsewhere.
>>> 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.
That is in and out of itself not wrong, it shouldn't be required but it's
definitely not wrong to do regardless of what's causing this.
> But it'd still be a good thing to trace the real cause.
Agreed, I'm hoping the animal owner can shed some light on this.
--
Daniel Gustafsson https://vmware.com/