Re: Missing include <openssl/x509.h> in be-secure-openssl.c?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Thomas Munro <thomas.munro@gmail.com>, 近藤雄太 <kondo@sraoss.co.jp>, Daniel Gustafsson <daniel@yesql.se>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, buildfarm@sraoss.co.jp
Date: 2021-11-04T13:54:07Z
Lists: pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes: > On Wed, Nov 03, 2021 at 11:45:26PM -0400, Tom Lane wrote: >> Yeah, I noted the comment about WIN32_LEAN_AND_MEAN in the >> stackoverflow thread too ... but as you say, it seems like >> that should make the problem less probable not more so. >> Still, it's hard to think of any other relevant change. > Yeah, I don't see how this could be linked to WIN32_LEAN_AND_MEAN. According to that stackoverflow thread, the unwanted #define of X509_NAME comes from <wincrypt.h>, and WIN32_LEAN_AND_MEAN prevents that from being immediately included by <windows.h>. The rough idea I have is that prior to 8162464a2, we sucked in that #define during postgres.h and then OpenSSL's headers were able to undo it. After 8162464a2, we don't read <wincrypt.h> during postgres.h, but some *other* header that be-secure-openssl.c is including after the OpenSSL headers is pulling it in, so that by the time we get to the body of the file the unwanted #define is active. I don't have either the resources or the interest to track down exactly where that happens; my thought was just to make be-secure-openssl.c's inclusions look more like fe-secure-openssl.c. But, if you'd like to pursue the details, feel free. regards, tom lane
Commits
-
contrib/sslinfo needs a fix too to make hamerkop happy.
- 568620dfd691 15.0 landed
-
Second attempt to silence SSL compile failures on hamerkop.
- 1241fcbd7e64 15.0 landed
-
Blind attempt to silence SSL compile failures on hamerkop.
- 24f9e49e430b 15.0 landed