> On 1 Nov 2021, at 14:33, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Daniel Gustafsson <dan...@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/
