=?ISO-2022-JP?B?GyRCNmFGI006QkAbKEI=?= writes:
> On Mon, 08 Nov 2021 12:05:24 -0500
> Tom Lane 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
On Mon, 08 Nov 2021 12:05:24 -0500
Tom Lane 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
> > during postgres.h, but some *other* header
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
> during postgres.h, but some *other* header that be-secure-openssl.c
> is including after the OpenSSL
Michael Paquier 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
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.
Thomas Munro writes:
> On Thu, Nov 4, 2021 at 4:33 PM Tom Lane 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
On Thu, Nov 4, 2021 at 4:33 PM Tom Lane 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
Thomas Munro 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
On Thu, Nov 4, 2021 at 3:39 PM Thomas Munro wrote:
> On Thu, Nov 4, 2021 at 3:16 PM Michael Paquier 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
On Thu, Nov 4, 2021 at 3:16 PM Michael Paquier 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
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 Wed, 03 Nov 2021 10:35:36 -0400
Tom Lane wrote:
> Michael Paquier 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
Michael Paquier 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
Michael Paquier 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
On Mon, Nov 01, 2021 at 11:15:32PM +0100, Daniel Gustafsson wrote:
> On 1 Nov 2021, at 14:33, Tom Lane 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
> On 1 Nov 2021, at 14:33, Tom Lane wrote:
>
> Daniel Gustafsson 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
Daniel Gustafsson 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
> On 1 Nov 2021, at 06:27, Michael Paquier 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.
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
> 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
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
20 matches
Mail list logo
