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
>>>
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
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
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
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
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
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
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
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.
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
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
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
*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
> 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
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
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,
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
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
-
26 matches
Mail list logo
