Обсуждение: Missing include in be-secure-openssl.c?
hamerkop has been failing recently [1] with
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(67): error C2143:
\215\\\225\266\203G\203\211\201[:')' \202\252 '(' \202\314\221O\202\311\202\240\202\350\202\334\202\271\202\361\201B
[c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(67): error C2091:
\212\326\220\224\202\315\212\326\220\224\202\360\225\324\202\271\202\334\202\271\202\361\201B
[c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(67): error C2059:
\215\\\225\266\203G\203\211\201[:')' [c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(67): error C2143:
\215\\\225\266\203G\203\211\201[:')' \202\252 '\222\350\220\224'
\202\314\221O\202\311\202\240\202\350\202\334\202\271\202\361\201B
[c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(67): error C2143:
\215\\\225\266\203G\203\211\201[:'{' \202\252 '\222\350\220\224'
\202\314\221O\202\311\202\240\202\350\202\334\202\271\202\361\201B
[c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(67): error C2059:
\215\\\225\266\203G\203\211\201[:'\222\350\220\224'
[c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(571): error C2065:
'x509name':\222\350\213`\202\263\202\352\202\304\202\242\202\310\202\242\216\257\225\312\216q\202\305\202\267\201B
[c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(571): error C2296: '*':
\226\263\214\370\202\305\202\267\201B\215\266\203I\203y\203\211\203\223\203h\202\311\202\315\214^'LPCSTR'
\202\252\216w\222\350\202\263\202\352\202\304\202\242\202\334\202\267\201B
[c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(576): error C2065:
'x509name':\222\350\213`\202\263\202\352\202\304\202\242\202\310\202\242\216\257\225\312\216q\202\305\202\267\201B
[c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(582): error C2065:
'x509name':\222\350\213`\202\263\202\352\202\304\202\242\202\310\202\242\216\257\225\312\216q\202\305\202\267\201B
[c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(623): error C2065:
'x509name':\222\350\213`\202\263\202\352\202\304\202\242\202\310\202\242\216\257\225\312\216q\202\305\202\267\201B
[c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(1377): error C2143:
\215\\\225\266\203G\203\211\201[:')' \202\252 '(' \202\314\221O\202\311\202\240\202\350\202\334\202\271\202\361\201B
[c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(1377): error C2091:
\212\326\220\224\202\315\212\326\220\224\202\360\225\324\202\271\202\334\202\271\202\361\201B
[c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(1377): error C2059:
\215\\\225\266\203G\203\211\201[:')' [c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(1377): error C2143:
\215\\\225\266\203G\203\211\201[:')' \202\252 '\222\350\220\224'
\202\314\221O\202\311\202\240\202\350\202\334\202\271\202\361\201B
[c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(1377): error C2143:
\215\\\225\266\203G\203\211\201[:'{' \202\252 '\222\350\220\224'
\202\314\221O\202\311\202\240\202\350\202\334\202\271\202\361\201B
[c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
c:\\build-farm-local\\buildroot\\head\\pgsql.build\\src\\backend\\libpq\\be-secure-openssl.c(1377): error C2059:
\215\\\225\266\203G\203\211\201[:'\222\350\220\224'
[c:\\build-farm-local\\buildroot\\HEAD\\pgsql.build\\postgres.vcxproj]
While I can't actually read these error messages, judging by the line
numbers and the ASCII fragments, it's spitting up on uses of the typedef
X509_NAME. There are also nearby warnings that look like some of the
associated functions aren't declared.
I observe that the OpenSSL docs say you are supposed to
#include <openssl/x509.h>
when using these functions. We are including that header in
some other modules, but not here. I speculate that we've gotten
away with that so far because of indirect inclusions; but hamerkop
must be running an OpenSSL version that has rearranged the headers
enough that that doesn't work anymore. That machine was offline
for awhile right before it started to fail, so it seems plausible
that it was rebuilt with some pretty bleeding-edge OpenSSL version.
Anyway, I propose adding that #include.
regards, tom lane
[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&dt=2021-10-29%2008%3A12%3A40
On Sun, Oct 31, 2021 at 06:45:47PM -0400, Tom Lane wrote: > I observe that the OpenSSL docs say you are supposed to > #include <openssl/x509.h> > when using these functions. We are including that header in > some other modules, but not here. I speculate that we've gotten > away with that so far because of indirect inclusions; but hamerkop > must be running an OpenSSL version that has rearranged the headers > enough that that doesn't work anymore. That machine was offline > for awhile right before it started to fail, so it seems plausible > that it was rebuilt with some pretty bleeding-edge OpenSSL version. Hmm. I have tested MSVC with 3.0.0 not so long ago, and this was working, but maybe they upgraded from 1.0.2 to 3.0.0? I'd be surprised if this was broken in some way in one of the stable releases as well. We've had our share of surprises with OpenSSL when it comes to major upgrades, but nothing that stood out when it came to minor release compatibility and ABI, AFAIK. > Anyway, I propose adding that #include. openssl/ssl.h includes openssl/x509.h if OPENSSL_NO_DEPRECATED_1_1_0 is not defined, but agreed that adding the header makes sense here. 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? -- Michael
Вложения
> On 1 Nov 2021, at 06:27, Michael Paquier <michael@paquier.xyz> wrote: > On Sun, Oct 31, 2021 at 06:45:47PM -0400, Tom Lane wrote: >> Anyway, I propose adding that #include. > > openssl/ssl.h includes openssl/x509.h if OPENSSL_NO_DEPRECATED_1_1_0 > is not defined, but agreed that adding the header makes sense here. 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. Looking at the headers in supported versions, the only real difference would be that 3.0.0 now defines #pragma once. For that to matter though it would mean it was included in the compilation unit before OPENSSL_API_COMPAT is defined from pg_config.h (or something entirely else as #pragma once is problematic and compiler dependent). Knowing the version used in hamerkop before and after (assuming it changed) would be quite interesting. > 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. -- Daniel Gustafsson https://vmware.com/
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?
>> 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
> 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/
On Mon, Nov 01, 2021 at 11:15:32PM +0100, Daniel Gustafsson wrote: > On 1 Nov 2021, at 14:33, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> 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. I would follow the practice of upstream to include both if were me to be consistent, but I'm also fine if you just add x509v3.h to be-secure-openssl.c. -- Michael
Вложения
Michael Paquier <michael@paquier.xyz> writes:
> I would follow the practice of upstream to include both if were me
> to be consistent, but I'm also fine if you just add x509v3.h to
> be-secure-openssl.c.
Another thing that's potentially relevant here is that
be-secure-openssl.c and fe-secure-openssl.c are including
ssl-related headers in different orders. Theoretically
that shouldn't make any difference, but ...
regards, tom lane
Michael Paquier <michael@paquier.xyz> writes:
> I would follow the practice of upstream to include both if were me
> to be consistent, but I'm also fine if you just add x509v3.h to
> be-secure-openssl.c.
24f9e49e4 has not fixed it, so I have no idea what to do next.
We definitely need some input from the machine's owner:
* what OpenSSL version is that?
* is HEAD being built any differently from v14 (seems like it must be)?
regards, tom lane
On Wed, 03 Nov 2021 10:35:36 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael@paquier.xyz> writes: > > I would follow the practice of upstream to include both if were me > > to be consistent, but I'm also fine if you just add x509v3.h to > > be-secure-openssl.c. > > 24f9e49e4 has not fixed it, so I have no idea what to do next. > We definitely need some input from the machine's owner: > > * what OpenSSL version is that? 1.0.2p (not upgraded recently) > * is HEAD being built any differently from v14 (seems like it must be)? We'll check it again, but there is no difference between HEAD and v14 branch. We simply added v14 branch to build recently, and did not change any settings of HEAD at that time. ------------------------------------------ Kondo Yuta <kondo@sraoss.co.jp>
On Thu, Nov 04, 2021 at 10:56:13AM +0900, 近藤雄太 wrote: > We'll check it again, but there is no difference between HEAD and v14 branch. > We simply added v14 branch to build recently, and did not change any settings of HEAD at that time. Thanks for checking. Could it be possible to copy-paste on this thread some of the buildfarm logs that show the compilation failure? No issues from me even if these are in Japanese. -- Michael
Вложения
On Thu, Nov 4, 2021 at 3:16 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Thu, Nov 04, 2021 at 10:56:13AM +0900, 近藤雄太 wrote:
> > We'll check it again, but there is no difference between HEAD and v14 branch.
> > We simply added v14 branch to build recently, and did not change any settings of HEAD at that time.
>
> Thanks for checking.
>
> Could it be possible to copy-paste on this thread some of the
> buildfarm logs that show the compilation failure? No issues from me
> even if these are in Japanese.
BTW It looks like these messages can be translated to Unicode like
this, in python2:
>>> print("\202\314\214^\202\252 1
\202\314\211\274\210\370\220\224\202\250\202\346\202\321\216\300\210\370\220\224\202\306\210\331\202\310\202\350\202\334\202\267\201B".decode("SJIS"))
の型が 1 の仮引数および実引数と異なります。
... which Google translates as:
"Different from formal and actual arguments of type 1"
On Thu, Nov 4, 2021 at 3:39 PM Thomas Munro <thomas.munro@gmail.com> wrote: > On Thu, Nov 4, 2021 at 3:16 PM Michael Paquier <michael@paquier.xyz> wrote: > > Could it be possible to copy-paste on this thread some of the > > buildfarm logs that show the compilation failure? No issues from me > > even if these are in Japanese. > > BTW It looks like these messages can be translated to Unicode like > this, in python2: Ahh, I think this contains some relevant bits, and we have indeed messed around with mentioned Windows headers in master. https://stackoverflow.com/questions/49504648/x509-name-macro-in-c-wont-compile/49504794 Here's the full transcode text (using previous trick with """-quotes to grab whole region of log), which makes it clear that X509_NAME is confusing it: FinalizeBuildStatus: ファイル ".\Release\pg_waldump\pg_waldump.tlog\unsuccessfulbuild" を削除しています。 ".\Release\pg_waldump\pg_waldump.tlog\pg_waldump.lastbuildstate" のタッチ タスクを実行しています。 プロジェクト "c:\build-farm-local\buildroot\HEAD\pgsql.build\pg_waldump.vcxproj" (既定のターゲット) のビルドが完了しました。 プロジェクト "c:\build-farm-local\buildroot\HEAD\pgsql.build\pgsql.sln" (既定のターゲット) のビルドが終了しました -- 失敗。 ビルドに失敗しました。 "c:\build-farm-local\buildroot\HEAD\pgsql.build\pgsql.sln" (既定のターゲット) (1) -> "c:\build-farm-local\buildroot\HEAD\pgsql.build\adminpack.vcxproj" (既定のターゲット) (9) -> "c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj" (既定のターゲット) (10) -> (ClCompile ターゲット) -> c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(577): warning C4047: '関数': 間接参照のレベルが 'X509_NAME *' と 'int' で異なっています。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(577): warning C4024: 'X509_NAME_get_text_by_NID': の型が 1 の仮引数および実引数と異なります。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(583): warning C4047: '関数': 間接参照のレベルが 'X509_NAME *' と 'int' で異なっています。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(583): warning C4024: 'X509_NAME_get_text_by_NID': の型が 1 の仮引数および実引数と異なります。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(624): warning C4047: '関数': 間接参照のレベルが 'X509_NAME *' と 'int' で異なっています。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(624): warning C4024: 'X509_NAME_print_ex': の型が 2 の仮引数および実引数と異なります。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(1282): warning C4013: 関数 'X509_NAME_to_cstring' は定義されていません。int 型の値を返す外部関数と見なします。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(1282): warning C4047: '関数': 間接参照のレベルが 'const char *' と 'int' で異なっています。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(1282): warning C4024: 'strlcpy': の型が 2 の仮引数および実引数と異なります。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(1291): warning C4047: '関数': 間接参照のレベルが 'const char *' と 'int' で異なっています。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(1291): warning C4024: 'strlcpy': の型が 2 の仮引数および実引数と異なります。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] "c:\build-farm-local\buildroot\HEAD\pgsql.build\pgsql.sln" (既定のターゲット) (1) -> "c:\build-farm-local\buildroot\HEAD\pgsql.build\adminpack.vcxproj" (既定のターゲット) (9) -> "c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj" (既定のターゲット) (10) -> (ClCompile ターゲット) -> c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(68): error C2143: 構文エラー: ')' が '(' の前にありません。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(68): error C2091: 関数は関数を返せません。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(68): error C2059: 構文エラー: ')' [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(68): error C2143: 構文エラー: ')' が '定数' の前にありません。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(68): error C2143: 構文エラー: '{' が '定数' の前にありません。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(68): error C2059: 構文エラー: '定数' [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(572): error C2065: 'x509name': 定義されていない識別子です。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(572): error C2296: '*': 無効です。左オペランドには型 'LPCSTR' が指定されています。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(577): error C2065: 'x509name': 定義されていない識別子です。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(583): error C2065: 'x509name': 定義されていない識別子です。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(624): error C2065: 'x509name': 定義されていない識別子です。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(1378): error C2143: 構文エラー: ')' が '(' の前にありません。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(1378): error C2091: 関数は関数を返せません。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(1378): error C2059: 構文エラー: ')' [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(1378): error C2143: 構文エラー: ')' が '定数' の前にありません。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(1378): error C2143: 構文エラー: '{' が '定数' の前にありません。 [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] c:\build-farm-local\buildroot\head\pgsql.build\src\backend\libpq\be-secure-openssl.c(1378): error C2059: 構文エラー: '定数' [c:\build-farm-local\buildroot\HEAD\pgsql.build\postgres.vcxproj] 11 個の警告 17 エラー 経過時間 00:09:26.25
Thomas Munro <thomas.munro@gmail.com> writes: > Ahh, I think this contains some relevant bits, and we have indeed > messed around with mentioned Windows headers in master. > https://stackoverflow.com/questions/49504648/x509-name-macro-in-c-wont-compile/49504794 Oooh .... note the comment there about This helped me too, but I found the simplest thing to do was just make sure the OpenSSL headers were #included last inmy source file. – So the fact that be-secure-openssl.c and fe-secure-openssl.c are including things in different orders *is* relevant. I'd previously discovered this bit in OpenSSL's headers (ossl_typ.h): # ifdef _WIN32 # undef X509_NAME ... #endif ... typedef struct X509_name_st X509_NAME; So that will work around the problem as long as it's #include'd after the relevant Windows headers. But I don't get the point about where HEAD is different from v14? be-secure-openssl.c isn't. regards, tom lane
On Thu, Nov 4, 2021 at 4:33 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > But I don't get the point about where HEAD is different from v14? > be-secure-openssl.c isn't. I don't understand what's going on and I don't have the headers to look at, but I was thinking that WIN32_LEAN_AND_MEAN must be causing a different state to be reached that somehow leaves the bad definition of X509_NAME in place. It's confusing though, because you'd hope that'd cause *less* stuff to get defined...
Thomas Munro <thomas.munro@gmail.com> writes:
> On Thu, Nov 4, 2021 at 4:33 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> But I don't get the point about where HEAD is different from v14?
>> be-secure-openssl.c isn't.
> I don't understand what's going on and I don't have the headers to
> look at, but I was thinking that WIN32_LEAN_AND_MEAN must be causing a
> different state to be reached that somehow leaves the bad definition
> of X509_NAME in place. It's confusing though, because you'd hope
> that'd cause *less* stuff to get defined...
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.
Anyway, my thought now is (1) move the openssl includes to
after system includes in both *-secure-openssl.c files,
and (2) add comments explaining why the order is critical.
But it's late here and I'm not going to mess with it right now.
If you want to take a shot at a blind fix before hamerkop's
next run, have at it.
regards, tom lane
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. > Anyway, my thought now is (1) move the openssl includes to > after system includes in both *-secure-openssl.c files, > and (2) add comments explaining why the order is critical. > But it's late here and I'm not going to mess with it right now. > If you want to take a shot at a blind fix before hamerkop's > next run, have at it. Reading through the error logs that Thomas has posted (thanks!), I have seen error patterns like that with a dirty build repository. So it could be possible that hamerkop is reusing a directory where some code has already been compiled on. -- Michael
Вложения
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
I wrote:
> 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.
This indeed seems to explain the compile failures, as hamerkop is
now getting through the "make" stage. However, it's now failing
in the plpython tests [1], apparently because Python itself doesn't
like the locale environment:
Fatal Python error: init_sys_streams: can't initialize sys standard streams
LookupError: unknown encoding: cp20127
Did something change on that machine in the last day or so? Because
plpython seems to have been working fine in the back branches.
regards, tom lane
[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&dt=2021-11-08%2010%3A08%3A22
On Mon, 08 Nov 2021 12:05:24 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wrote: > > 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. > > This indeed seems to explain the compile failures, as hamerkop is > now getting through the "make" stage. However, it's now failing > in the plpython tests [1], apparently because Python itself doesn't > like the locale environment: > > Fatal Python error: init_sys_streams: can't initialize sys standard streams > LookupError: unknown encoding: cp20127 > > Did something change on that machine in the last day or so? Because > plpython seems to have been working fine in the back branches. > > regards, tom lane > > [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&dt=2021-11-08%2010%3A08%3A22 Sorry. The error was caused by using "chcp 20127" in the build script when we were trying to make the compiler error messages in English. We removed "chcp 20127" and run the build script. It seems to be building fine. Please check it. ------------------------------------------ Kondo Yuta <kondo@sraoss.co.jp>
=?ISO-2022-JP?B?GyRCNmFGI006QkAbKEI=?= <kondo@sraoss.co.jp> writes:
> On Mon, 08 Nov 2021 12:05:24 -0500
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This indeed seems to explain the compile failures, as hamerkop is
>> now getting through the "make" stage. However, it's now failing
>> in the plpython tests [1], apparently because Python itself doesn't
>> like the locale environment:
>> Fatal Python error: init_sys_streams: can't initialize sys standard streams
>> LookupError: unknown encoding: cp20127
>> Did something change on that machine in the last day or so? Because
>> plpython seems to have been working fine in the back branches.
> Sorry. The error was caused by using "chcp 20127" in the build script when
> we were trying to make the compiler error messages in English.
Ah so. Well, thanks for trying anyway ;-)
Looks like hamerkop is all green again, so we've resolved this issue.
regards, tom lane