Hi Andrew,
On Tue, Jun 19, 2018 at 01:25:58PM +0900, Michael Paquier wrote:
> On Tue, Jun 19, 2018 at 12:01:39AM -0400, Andrew Dunstan wrote:
>>> In my own environment I have a copy of ssleay32.dll and libeay32.dll in
>>> c:\Windows\System32 so as that I don't get any complaints when running
>>> r
On Tue, Jun 19, 2018 at 12:01:39AM -0400, Andrew Dunstan wrote:
>> In my own environment I have a copy of ssleay32.dll and libeay32.dll in
>> c:\Windows\System32 so as that I don't get any complaints when running
>> regression tests. Is your environment using something specific?
>
> I have adjust
On 06/18/2018 11:13 PM, Michael Paquier wrote:
On Tue, Jun 19, 2018 at 09:11:20AM +0900, Michael Paquier wrote:
On Mon, Jun 18, 2018 at 10:57:34AM +0900, Michael Paquier wrote:
As there is visibly a consensus for HEAD, for now I propose to just
process with the previous patch on only the mas
On Tue, Jun 19, 2018 at 09:11:20AM +0900, Michael Paquier wrote:
> On Mon, Jun 18, 2018 at 10:57:34AM +0900, Michael Paquier wrote:
> > As there is visibly a consensus for HEAD, for now I propose to just
> > process with the previous patch on only the master branch then. This
> > will address the
On Mon, Jun 18, 2018 at 10:57:34AM +0900, Michael Paquier wrote:
> As there is visibly a consensus for HEAD, for now I propose to just
> process with the previous patch on only the master branch then. This
> will address the open item. Any objections to that?
As there is a consensus at least on
On Sun, Jun 17, 2018 at 10:57:16AM -0400, Tom Lane wrote:
> If we're just leaving them undefined, isn't this purely cosmetic?
> At least, that was what I understood to be the reasoning for leaving
> such symbols out of pg_config.h.win32 in the past.
>
> I'm on board with making things more consiste
Andrew Dunstan writes:
>> On Thu, Jun 14, 2018 at 10:49:52AM +0900, Michael Paquier wrote:
>> Okay, this is still an open item. Are there any objections to the
>> previous patch applied on master and the addition of the following
>> undefined flags to pg_config.h.win32 for back-branches? Here is
On 06/17/2018 08:15 AM, Michael Paquier wrote:
On Thu, Jun 14, 2018 at 10:49:52AM +0900, Michael Paquier wrote:
Thoughts?
Okay, this is still an open item. Are there any objections to the
previous patch applied on master and the addition of the following
undefined flags to pg_config.h.win32
On Thu, Jun 14, 2018 at 10:49:52AM +0900, Michael Paquier wrote:
> Thoughts?
Okay, this is still an open item. Are there any objections to the
previous patch applied on master and the addition of the following
undefined flags to pg_config.h.win32 for back-branches? Here is the
list of flags whic
On Wed, Jun 13, 2018 at 08:55:46PM -0400, Andrew Dunstan wrote:
> I installed 1.1.0h and got errors you can see on the buildfarm. I've now
> installed 1.0.2o and everything is good.
Good thing you tested that. I have just used the LTS 1.0.2 for my
tests. And there are a couple of problems here.
On 06/12/2018 08:07 PM, Michael Paquier wrote:
On Tue, Jun 12, 2018 at 04:51:59PM -0400, Andrew Dunstan wrote:
On 06/12/2018 10:51 AM, Andrew Dunstan wrote:
meanwhile, Bowerbird (MSVC) is on 1.0.1d, lorikeet (Cygwin64) is on
1.0.2d and jacana (Mingw) doesn't build with openssl.
I will look
On Wed, Jun 13, 2018 at 02:35:23PM +1200, Thomas Munro wrote:
> It should be disabled on Windows, as you have it.
>
> ldap_initialize() is a non-standard extension that provides a way to
> use "ldaps" with OpenLDAP, but we don't even support using OpenLDAP on
> Windows. We know how to use Win32's
On Wed, Jun 13, 2018 at 2:06 PM, Michael Paquier wrote:
> HAVE_LDAP_INITIALIZE is added in the list, but this is disabled as I
> could not test it. It could always be possible to revisit that later.
> Thomas, what do you think?
It should be disabled on Windows, as you have it.
ldap_initialize()
On Wed, Jun 13, 2018 at 09:07:20AM +0900, Michael Paquier wrote:
> What kind of failures are you seeing? I just compiled Postgres two days
> ago with MSVC and OpenSSL 1.0.2o (oldest version with a Windows
> installer I could find), and that was able to compile. On HEAD, OpenSSL
> should be suppor
On Tue, Jun 12, 2018 at 04:51:59PM -0400, Andrew Dunstan wrote:
> On 06/12/2018 10:51 AM, Andrew Dunstan wrote:
>> meanwhile, Bowerbird (MSVC) is on 1.0.1d, lorikeet (Cygwin64) is on
>> 1.0.2d and jacana (Mingw) doesn't build with openssl.
>>
>> I will look at upgrading bowerbird ASAP.
>
> Well,
On 06/12/2018 10:51 AM, Andrew Dunstan wrote:
meanwhile, Bowerbird (MSVC) is on 1.0.1d, lorikeet (Cygwin64) is on
1.0.2d and jacana (Mingw) doesn't build with openssl.
I will look at upgrading bowerbird ASAP.
Well, that crashed and burned. What versions of openssl are we supporting
On 06/12/2018 10:40 AM, Christian Ullrich wrote:
*On 2018-06-12 16:21, Jonathan S. Katz wrote:
On Jun 3, 2018, at 4:29 AM, Michael Paquier
wrote:
A script which reports the version of OpenSSL should be simple enough
for MSVC. And I am ready to bet that at least hamerkop is not using
Ope
*On 2018-06-12 16:21, Jonathan S. Katz wrote:
On Jun 3, 2018, at 4:29 AM, Michael Paquier wrote:
A script which reports the version of OpenSSL should be simple enough
for MSVC. And I am ready to bet that at least hamerkop is not using
OpenSSL 1.0.2, so a simple switch would most likely caus
> On Jun 3, 2018, at 4:29 AM, Michael Paquier wrote:
>
> On Sat, Jun 02, 2018 at 05:20:57PM -0400, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> On 02/06/18 17:09, Tom Lane wrote:
More concerning is that RHEL6 is on 1.0.1e:
>>
>>> I was only thinking of requiring 1.0.2 on Windows.
>>
On Sat, Jun 02, 2018 at 05:20:57PM -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 02/06/18 17:09, Tom Lane wrote:
>>> More concerning is that RHEL6 is on 1.0.1e:
>
>> I was only thinking of requiring 1.0.2 on Windows.
>
> Ah. Personally, I don't care about that case, but maybe somebo
Heikki Linnakangas writes:
> On 02/06/18 17:09, Tom Lane wrote:
>> More concerning is that RHEL6 is on 1.0.1e:
> I was only thinking of requiring 1.0.2 on Windows.
Ah. Personally, I don't care about that case, but maybe somebody
else wants to speak for it?
regards, tom
On 02/06/18 17:09, Tom Lane wrote:
Michael Paquier writes:
... Making HAVE_X509_GET_SIGNATURE_NID a hard requirement bumps the
minimal version of OpenSSL supported to 1.0.2, which is something I
would not feel much sorry about either like Heikki, as I have heard of
many vendors maintaining Open
Michael Paquier writes:
> Navigating through the logs of the buildfarm, it is actually not really
> easy to find out which version of OpenSSL a build is using at compile
> time. Perhaps we would want first to report this information?
+1 if we can figure a way to do it. ISTR having looked for a
On Sat, Jun 02, 2018 at 01:24:41PM -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
>> But yeah, clearly those are missing from pg_config.h.win32 at the
>> moment. It's not actually clear to me, when that file is (supposed to
>> be) updated. Are you supposed to remember to update it, whenever
On Sat, Jun 02, 2018 at 01:19:41PM -0400, Heikki Linnakangas wrote:
> I wouldn't be too sorry to just bump our minimum requirements for Windows,
> in v11. Assuming that recent-enough versions of OpenLSAP and OpenSSL are
> readily available on Windows.
s/OpenLSAP/OpenLDAP/.
It may be better to loo
Heikki Linnakangas writes:
> But yeah, clearly those are missing from pg_config.h.win32 at the
> moment. It's not actually clear to me, when that file is (supposed to
> be) updated. Are you supposed to remember to update it, whenever you
> update pg_config.h.in? Or does someone update it with t
On 29/05/18 17:15, Michael Paquier wrote:
Hi all,
While reviewing the MSVC code, I have noticed that pg_config.h.win32 is
forgetting about a couple of flags defined in pg_config.h.in for v11
development. Forgetting some of them is problematic, and here are the
ones I spotted:
- HAVE_LDAP_INITIA
Hi all,
While reviewing the MSVC code, I have noticed that pg_config.h.win32 is
forgetting about a couple of flags defined in pg_config.h.in for v11
development. Forgetting some of them is problematic, and here are the
ones I spotted:
- HAVE_LDAP_INITIALIZE
- HAVE_X509_GET_SIGNATURE_NID
- HAVE_SS
28 matches
Mail list logo
