Re: HEAD build error on Fedora 39
Hi Andrew, Devrim, I'm seeing these errors on MacOS: -- /opt/local/Current_v15/bin/xsltproc --nonet --path . --path . --stringparam pg.version '17beta1' stylesheet.xsl postgres-full.xml I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl warning: failed to load external entity " http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl; compilation error: file stylesheet.xsl line 6 element import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/common/entities.ent stylesheet-html-common.xsl:4: warning: failed to load external entity " http://docbook.sourceforge.net/release/xsl/current/common/entities.ent; %common.entities; -- I've set SGML_CATALOG_FILES to point to the catalog from docbook-xsl. Am I missing something? On Mon, Apr 15, 2024 at 4:06 PM Andrew Dunstan wrote: > > On 2024-04-15 Mo 05:59, Devrim Gündüz wrote: > > Hi, > > I'm unable to build the latest snapshot on my Fedora 39 box. I think > this problem appeared before the weekend (not sure, though). This is > libxml 2.10.4: > > === > '/usr/bin/perl' > ../../../src/backend/utils/activity/generate-wait_event_types.pl --docs > ../../../src/backend/utils/activity/wait_event_names.txt > /usr/bin/xmllint --nonet --path . --path . --output postgres-full.xml --noent > --valid postgres.sgml > I/O error : Attempt to load network entity > http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd > postgres.sgml:21: warning: failed to load external entity > "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; > <http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd> > ]> > > > It's working on my Fedora 39. This error suggests to me that you don't > have docbook-dtds installed. If you do, then I don't know :-) > > cheers > > andrew > > -- > Andrew Dunstan > EDB: https://www.enterprisedb.com > > -- Sandeep Thakkar
Re: zlib detection in Meson on Windows broken?
Hi Dave,
On Tue, May 21, 2024 at 3:12 PM Dave Page wrote:
> Hi Sandeep, Nazir,
>
> On Tue, 21 May 2024 at 10:14, Nazir Bilal Yavuz
> wrote:
>
>> Hi,
>>
>> On Tue, 21 May 2024 at 10:20, Sandeep Thakkar
>> wrote:
>> >
>> > Hi Dave,
>> >
>> > Is the .pc file generated after the successful build of zlib? If yes,
>> then meson should be able to detect the installation ideally
>>
>> If meson is not able to find the .pc file automatically, using 'meson
>> setup ... --pkg-config-path $ZLIB_PC_PATH' might help.
>>
>
> The problem is that on Windows there are no standard locations for a
> Unix-style development library installation such as this, so the chances
> are that the .pc file will point to entirely the wrong location.
>
> For example, please see
> https://github.com/dpage/winpgbuild/actions/runs/9172187335 which is a
> Github action that builds a completely vanilla zlib using VC++. If you look
> at the uploaded artefact containing the build output and example the .pc
> file, you'll see it references /zlib as the location, which is simply where
> I built it in that action. On a developer's machine that's almost certainly
> not going to be where it actually ends up. For example, on the pgAdmin
> build farm, the dependencies all end up in C:\build64\[whatever]. On the
> similar Github action I'm building for PostgreSQL, that artefact will be
> unpacked into /build/zlib.
>
>
The above link returned 404. But I found a successful build at
https://github.com/dpage/winpgbuild/actions/runs/9175426807. I downloaded
the artifact but didn't find .pc file as I wanted to look into the content
of that file.
I had a word with Murali who mentioned he encountered a similar issue while
building PG17 on windows. He worked-around is by using a template .pc file
that includes these lines:
--
prefix=${pcfiledir}/../..
exec_prefix=${prefix}
libdir=${prefix}/lib
sharedlibdir=${prefix}/lib
includedir=${prefix}/include
--
But in general I agree with you on the issue of Meson's dependency on
pkgconfig files to detect the third party libraries.
Of course, for my own builds I can easily make everything use consistent
> directories, however most people who are likely to want to build PostgreSQL
> may not want to also build all the dependencies themselves as well, as some
> are a lot more difficult than zlib. So what tends to happen is people find
> third party builds or upstream official builds.
>
> I would therefore argue that if the .pc file that's found doesn't provide
> correct paths for us, then Meson should fall back to searching in the paths
> specified on its command line for the appropriate libraries/headers (which
> is what it does for OpenSSL for example, as that doesn't include a .pc
> file). This is also what happens with PG16 and earlier.
>
> One other thing I will note is that PG16 and earlier try to use the wrong
> filename for the import library. For years, it's been a requirement to do
> something like this: "copy \zlib\lib\zlib.lib \zlib\lib\zdll.lib" to make a
> build succeed against a "vanilla" zlib build. I haven't got as far as
> figuring out if the same is true with Meson yet.
>
> --
> Dave Page
> pgAdmin: https://www.pgadmin.org
> PostgreSQL: https://www.postgresql.org
> EDB: https://www.enterprisedb.com
>
>
--
Sandeep Thakkar
Re: zlib detection in Meson on Windows broken?
Hi Dave, Is the .pc file generated after the successful build of zlib? If yes, then meson should be able to detect the installation ideally On Mon, May 20, 2024 at 4:28 PM Dave Page wrote: > Hi > > I'm working on updating the build of PostgreSQL that pgAdmin uses in its > Windows installers to use Meson ready for the v17 release. I'm using Visual > Studio 2022, on Windows Server 2022. > > I've been unable to persuade Meson to detect zlib, whilst OpenSSL seems to > be fine. > > The dependencies have been built and installed as follows: > > mkdir c:\build64 > > wget https://zlib.net/zlib-1.3.2.tar.gz > tar -zxvf zlib-1.3.2.tar.gz > cd zlib-1.3.2 > cmake -DCMAKE_INSTALL_PREFIX=C:/build64/zlib -G "Visual Studio 17 2022" . > msbuild ALL_BUILD.vcxproj /p:Configuration=Release > msbuild RUN_TESTS.vcxproj /p:Configuration=Release > msbuild INSTALL.vcxproj /p:Configuration=Release > cd .. > > wget https://www.openssl.org/source/openssl-3.0.13.tar.gz > tar -zxvf openssl-3.0.13.tar.gz > cd openssl-3.0.013 > perl Configure VC-WIN64A no-asm --prefix=C:\build64\openssl no-ssl3 > no-comp > nmake > nmake test > nmake install > cd .. > > This results in the following headers and libraries being installed for > zlib: > > C:\Users\dpage\git\postgresql>dir C:\build64\zlib\include > Volume in drive C has no label. > Volume Serial Number is 3AAD-5864 > > Directory of C:\build64\zlib\include > > 17/05/2024 15:56 . > 17/05/2024 15:56 .. > 17/05/2024 15:5417,096 zconf.h > 22/01/2024 19:3296,829 zlib.h >2 File(s)113,925 bytes >2 Dir(s) 98,842,726,400 bytes free > > C:\Users\dpage\git\postgresql>dir C:\build64\zlib\lib > Volume in drive C has no label. > Volume Serial Number is 3AAD-5864 > > Directory of C:\build64\zlib\lib > > 17/05/2024 17:01 . > 17/05/2024 15:56 .. > 17/05/2024 15:5516,638 zlib.lib > 17/05/2024 15:55 184,458 zlibstatic.lib >2 File(s)201,096 bytes >2 Dir(s) 98,842,726,400 bytes free > > I then attempt to build PostgreSQL: > > meson setup build > -Dextra_include_dirs=C:/build64/openssl/include,C:/build64/zlib/include > -Dextra_lib_dirs=C:/build64/openssl/lib,C:/build64/zlib/lib -Dssl=openssl > -Dzlib=enabled --prefix=c:/build64/pgsql > > Which results in the output in output.txt, indicating that OpenSSL was > correctly found, but zlib was not. I've also attached the meson log. > > I have very little experience with Meson, and even less interpreting it's > logs, but it seems to me that it's not including the extra lib and include > directories when it runs the test compile, given the command line it's > reporting: > > cl > C:\Users\dpage\git\postgresql\build\meson-private\tmpg_h4xcue\testfile.c > /nologo /showIncludes /utf-8 /EP /nologo /showIncludes /utf-8 /EP /Od /Oi- > > Bug, or am I doing something silly? > > > -- > Dave Page > pgAdmin: https://www.pgadmin.org > PostgreSQL: https://www.postgresql.org > EDB: https://www.enterprisedb.com > > -- Sandeep Thakkar
Re: "ERROR: latch already owned" on gharial
Thanks Robert. We are receiving the alerts from buildfarm-admins for anole and gharial not reporting. Who can help to stop these? Thanks On Wed, Jul 6, 2022 at 1:27 AM Robert Haas wrote: > On Sun, Jul 3, 2022 at 11:51 PM Thomas Munro > wrote: > > On Wed, Jun 1, 2022 at 12:55 AM Robert Haas > wrote: > > > OK, I have access to the box now. I guess I might as well leave the > > > crontab jobs enabled until the next time this happens, since Thomas > > > just took steps to improve the logging, but I do think these BF > > > members are overdue to be killed off, and would like to do that as > > > soon as it seems like a reasonable step to take. > > > > A couple of months later, there has been no repeat of that error. I'd > > happily forget about that and move on, if you want to decommission > > these. > > I have commented out the BF stuff in crontab on that machine. > > -- > Robert Haas > EDB: http://www.enterprisedb.com > > > -- Sandeep Thakkar
Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.
Hi, Do we see any solution to this issue? or using the older SDK is the way to go? On Thu, May 20, 2021 at 2:04 PM Dave Page wrote: > > > On Tue, Mar 30, 2021 at 6:58 AM Tom Lane wrote: > >> Thomas Munro writes: >> > I'll move it when committing. I'll let this patch sit for another day >> > to see if any other objections show up. >> >> FWIW, I remain fairly strongly against this, precisely because of the >> point that it requires us to start using a randomly different >> feature-probing technology anytime Apple decides that they're going to >> implement some standard API that they didn't before. Even if it works >> everywhere for preadv/pwritev (which we won't know in advance of >> buildfarm testing, and maybe not then, since detection failures will >> probably be silent), it seems likely that we'll hit some case in the >> future where this interacts badly with some other platform's weirdness. >> We haven't claimed in the past to support MACOSX_DEPLOYMENT_TARGET, >> and I'm not sure we should start now. How many people actually care >> about that? >> > > I missed this earlier - it's come to my attention through a thread on the > -packagers list. Adding my response on that thread here for this audience: > > The ability to target older releases with a newer SDK is essential for > packages such as the EDB PostgreSQL installers and the pgAdmin community > installers. It's very difficult (sometimes impossible) to get older OS > versions on new machines now - Apple make it very hard to download old > versions of macOS (some can be found, others not), and they won't always > work on newer hardware anyway so it's really not feasible to have all the > build machines running the oldest version that needs to be supported. > > FYI, the pgAdmin and PG installer buildfarms have > -mmacosx-version-min=10.12 in CFLAGS etc. to handle this, which is > synonymous with MACOSX_DEPLOYMENT_TARGET. We've been successfully building > packages that way for a decade or more. > > -- > Dave Page > Blog: https://pgsnake.blogspot.com > Twitter: @pgsnake > > EDB: https://www.enterprisedb.com > > -- Sandeep Thakkar
Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.
should be fixing the root cause(improper > detection of target deployment API availability in probes) in some > way as this will probably continue to be an issue otherwise, we already > know that improving PG_SYSROOT selection can not fix the root issue > but rather tries to workaround it in a way that is pretty much guaranteed > to be brittle. > > Is there any approach to fixing the root cause of this issue that you think > would be acceptable? > > > > > regards, tom lane > > > -- Sandeep Thakkar
Re: PG v12.2 - Setting jit_above_cost is causing the server to crash
Hi, On Thu, Feb 27, 2020 at 6:23 PM Dave Page wrote: > Hi > > On Thu, Feb 27, 2020 at 12:41 PM Tom Lane wrote: > >> Aditya Toshniwal writes: >> > On Mon, Feb 24, 2020 at 12:46 PM Andres Freund >> wrote: >> >> This isn't reproducible here. Are you sure that you're running on a >> >> clean installation? >> >> > Yes I did a fresh installation using installer provided here - >> > https://www.enterprisedb.com/downloads/postgresql >> >> There is apparently something wrong with the JIT stuff in EDB's 12.2 >> build for macOS. At least, that's the conclusion I came to after >> off-list discussion with the submitter of bug #16264, which has pretty >> much exactly this symptom (especially if you're seeing "signal 9" >> reports in the postmaster log). For him, either disabling JIT or >> reverting to 12.1 made it go away. >> > > We've been looking into this; > > Apple started a notarisation process some time ago, designed to mark their > applications as conforming to various security requirements, but prior to > Catalina it was essentially optional. When Catalina was released, they made > notarisation for distributed software a requirement, but had the process > issue warnings for non-compliance. As-of the end of January, those warnings > became hard errors, so now our packages must be notarised, and for that to > happen, must be hardened by linking with a special runtime and having > securely time stamped signatures on every binary before being checked and > notarised as such by Apple. Without that, users would have to disable > security features on their systems before they could run our software. > > Our packages are being successfully notarised at the moment, because > that's essentially done through a static analysis. We can (and have) added > what Apple call an entitlement in test builds which essentially puts a flag > in the notarisation for the product that declares that it will do JIT > operations, however, it seems that this alone is not enough and that in > addition to the entitlement, we also need to include the MAP_JIT flag in > mmap() calls. See > https://developer.apple.com/documentation/security/hardened_runtime and > https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-jit > > We're working on trying to test a patch for that at the moment. > > We have fixed the issue. To explain in brief, It was related to the hardened runtime. Hardening the runtime can produce such issues, and therefore Apple provides the runtime exceptions. We were previously using an entitlement "com.apple.security.cs.disable-library-validation" for the app bundle and then tried adding "com.apple.security.cs.allow-unsigned-executable-memory" but still the query would crash the server process when JIT is enabled. Later we applied these entitlements to the PG binaries (postgres, pg_ctl and others) and the bundles (llvmjit.so and others) which actually resolved the problem. The updates will be released in a couple of days. -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- Sandeep Thakkar
Re: PostgreSQL 12 Beta 4
Hi What's the date for PostgreSQL 12 GA? On Fri, Sep 6, 2019 at 1:57 AM Jonathan S. Katz wrote: > Hi, > > PostgreSQL 12 Beta 4 will be released on 2019-09-12. Please make sure > that fixes for bugs and other open items[1] are committed by the end of > the weekend. > > Thanks for all of your efforts in getting PostgreSQL 12 ready for > general availability! > > Jonathan > > [1] https://wiki.postgresql.org/wiki/PostgreSQL_12_Open_Items > > -- Sandeep Thakkar
Re: Problem with EDB 11.0 Windows x64 distributions
On Thu, Oct 25, 2018 at 4:58 PM Christian Ullrich wrote: > * Sandeep Thakkar wrote: > > > There shouldn't be any problem with the installer (in non extract-only > > mode) and all the dependencies should be in place. Let us know if any > > binary is not working. For extract-only mode, let me confirm and fix the > > issues if any. > > Sorry, I do not use the installer in install mode; it's too black a box > for me. > > > Also, bin/libwinpthread-1.dll and bin/zilb1.dll were missing in zip > > archive which I just added. > > The file download on your web site is still 11.0-2, and the files are > still missing from it. Should it have updated (to -3?) by now? > > You talking about Zip archive? I can see the missing DLLs in it: $ unzip -l postgresql-11.0-2-windows-x64-binaries.zip | grep libwin 52736 10-24-18 20:59 pgsql/bin/libwinpthread-1.dll $ unzip -l postgresql-11.0-2-windows-x64-binaries.zip | grep zlib1 86528 10-24-18 20:59 pgsql/bin/zlib1.dll The version is same because the files in archive should match the ones bundled in the installer. 11.0-3 will include a fix for extract-only issue with the installer. > -- > Christian > -- Sandeep Thakkar
Re: Problem with EDB 11.0 Windows x64 distributions
Hi Christian, There shouldn't be any problem with the installer (in non extract-only mode) and all the dependencies should be in place. Let us know if any binary is not working. For extract-only mode, let me confirm and fix the issues if any. Also, bin/libwinpthread-1.dll and bin/zilb1.dll were missing in zip archive which I just added. Thanks. On Wed, Oct 24, 2018 at 7:16 PM Christian Ullrich wrote: > Hello, > > there are some problems with the 11.0 EDB installers and binary archives > for Windows x64: > > - bin/libwinpthread-1.dll is only in the installer > >This is a dependency of libintl-9.dll, so without it, nearly >everything in the Zip archive does not work. > > - zlib1.dll is only in the installer > >No backups, no replication, no logical replication. > > - bin/libcurl.dll is only in the Zip archive > >Needed by bin/stackbuilder.exe , but ... > > - StackBuilder (all of it) is only in the Zip archive > >... and so are all the wxWidgets DLLs. At least I cannot get >the installer to --extract-only it. > > - bin/libcurl.lib is present in both > >It is not needed, is it? > > > Files involved: > > - postgresql-11.0-2-windows-x64-binaries.zip >SHA1: 167c37a61a60737d9e3461b845fc2baa8db34bd5 > > - postgresql-11.0-2-windows-x64.exe (--extract-only 1) >SHA1: 67a0e27e69375404df8967ab81383d26f22c94b5 > > -- > Christian > -- Sandeep Thakkar
Re: Perl 5.26 and windows build system
Hi On Wed, Oct 17, 2018 at 2:08 PM Victor Wagner wrote: > Colleagues, > > Since Active State stopped to distribute perl 5.22, we decided to > upgrade installer builds to most use recent version available > (5.26.1.2601 now). > > But upstream perl changes policy around this version and no longer > adds current directory to the module search path. > > This doesn't break work of build.pl, which allready handles module > search path itself, but breaks install.pl, mkvcbuild.pl and > vcregress.pl, which > expect to be started from src/tools/msvc. > > Simple adding > > use lib "."; > > to the beginning of these script solves problem. > > BTW, have anyone experienced some success using Strawberry perl instead > of Active perl both for building postgres and as PL/Perl engine? > > We observed the same issue with Strawberry Perl 5.26. We use 5.24 to execute the build.pl. > Active State seems to abandon support for 32-bit windows and strawberry > perl license allows redistribution. > -- > > > -- Sandeep Thakkar
Re: PostgreSQL 11 RC1 + GA Dates
Hi, On Tue, Oct 2, 2018 at 7:28 PM Jonathan S. Katz wrote: > Hi, > > Based on the current status of the open items and where we are at in the > release cycle, the date for the first release candidate of PostgreSQL 11 > will be 2018-10-11. > > If all goes well with RC1, the PostgreSQL 11.0 GA release will be > 2018-10-18. This is subject to change if we find any issues during the > RC1 period that indicate we need to make an additional release candidate > prior to going GA. > > So, is 11.0 GA release planned in this week? > To the entire community, thank you for all of your hard work on > developing PostgreSQL 11. It is exciting that we are finally at this > point where we are ready to make our major release. > > Jonathan > > -- Sandeep Thakkar
Re: [HACKERS] git down
Hi, I'm seeing this warning (git.postgresql.org[0: 2620:122:b000:7::243]: errno=Network is unreachable) on one of the buildfarm animals (anole) from last few weeks. The git version is 1.7.4.2. When I use https, it errors "fatal: cannot exec 'git-remote-https': Permission denied" On Mon, Oct 30, 2017 at 2:32 PM, Magnus Hagander wrote: > > > On Mon, Oct 30, 2017 at 2:35 AM, Andreas Karlsson > wrote: > >> On 10/27/2017 10:51 PM, Erik Rijkers wrote: >> >>> git.postgresql.org is down/unreachable >>> >>> ( git://git.postgresql.org/git/postgresql.git ) >>> >> >> Yes, I noticed this too, but https://git.postgresql.org/git >> /postgresql.git still works fine. >> >> I guess it makes sense to remove unencrypted access, but in that case >> https://git.postgresql.org/gitweb/?p=postgresql.git;a=summary should not >> advertise supporting the git protocol. I have not seen any announcement >> either, but that could just be me not paying enough attention. > > > We definitely still support the unencrypted git protocol. I do recommend > using https, but that doesn't mean git shouldn't work. There seems to have > been some network issues and the git daemon doesn't do a very good job of > handling hung sessions. I've cleaned up for now and it seems to be working > again, and we'll do some more digging into what actually was the root > cause. > > > -- > Magnus Hagander > Me: https://www.hagander.net/ <http://www.hagander.net/> > Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/> > -- Sandeep Thakkar
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
On Wed, Aug 22, 2018 at 5:32 PM, Andres Freund wrote: > Hi, > > On 2018-08-22 17:17:27 +0530, Sandeep Thakkar wrote: > > > We build windows binaries (>=9.3) on Windows 7 and Windows Server 2012 > R2. > > For 9.3, the Visual Studio version is 2010 and for 9.4 and v10, we use > > 2013. For v11, we use 2017. > > Sndeep: Thanks for the information. Did you ever encounter problems (at > build or during runtime) with using those binaries on older platforms? > > IIRC when the binaries were built with VC++ 2013 on 9.4, we had problems running them on XP and hence we had used "/p:PlatformToolset=v120_xp" option to msbuild during build time. From v10, we stopped using that toolset and instead used the default one i.e v120 > Everyone: Given the fact that all the people building windows packages > currently use a new enough stack by a fair margin, I think we should > conclude that there's no obstacle on the windows side of things. > > > If we agree on that, I'm going to propose a patch that includes: > - relevant cleanups to configure > - adapts sources.sgml to refer to C99 instead of C89 > - add some trivial conversions to for(int i;;) and struct initializers, > so the relevant old animals fail > - adds a configure check to enable errors with vla usage (-Werror=vla) > > Questions: > > - do we want to make declarations at arbitrary points errors? It's > already a warning currently. > - other new restrictions that we want to introduce at the same time? > > Greetings, > > Andres Freund > -- Sandeep Thakkar
Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
On Wed, Aug 22, 2018 at 4:59 AM, Andres Freund wrote: > On 2018-08-21 17:58:00 -0400, Andrew Dunstan wrote: > > > > > > On 08/21/2018 04:49 PM, Andres Freund wrote: > > > On 2018-08-21 11:09:15 -0700, Joshua D. Drake wrote: > > > > On 08/21/2018 11:06 AM, Andrew Dunstan wrote: > > > > > > > > > > > > > > > XP at least is essentially a dead platform for us. My animals are > not > > > > > able to build anything after release 10. > > > > I wouldn't think XP should even be on our list anymore. Microsoft > hasn't > > > > supported it in 4 years. > > > XP isn't the only thing relevant here, vista and 2008 R1 are in the > same > > > class. > > > > > > > > > I do have a machine in my laptop graveyard with Vista. The only WS2008 > > instace I have available is R2 and AWS doesn't seem to have any AMIs for > R1. > > > > Honestly, I don't think these matter terribly much. Anyone building now > is > > not likely to be targeting them. > > I agree, I think we should just decree that the minimum is MSVC 2013 and > that people building 12 need to deal with that. I would personally > *additionally* would say that we officially don't support *running* (not > compiling) on XP, 2003, 2008R1 and Vista (all unsupported by MS) - but > that's a somewhat orthogonal decision. > > We build windows binaries (>=9.3) on Windows 7 and Windows Server 2012 R2. For 9.3, the Visual Studio version is 2010 and for 9.4 and v10, we use 2013. For v11, we use 2017. > Greetings, > > Andres Freund > -- Sandeep Thakkar
Re: C99 compliance for src/port/snprintf.c
Hi On Thu, Aug 16, 2018 at 6:30 PM, Andres Freund wrote: > Hi, > > On 2018-08-16 14:28:25 +0200, Peter Eisentraut wrote: > > On 16/08/2018 01:06, Andres Freund wrote: > > > So it looks like msvc 2013 might be the relevant requirement. > > > > According to my research (completely untested in practice), you need > > 2010 for mixed code and declarations and 2013 for named initialization > > of structs. > > > > I wonder what raising the msvc requirement would imply for supporting > > older Windows versions. > > One relevant tidbit is that afaict 2013 still allows *targeting* older > versions of windows, down to XP and 2003, while requiring a newer > platforms to run. See: > https://docs.microsoft.com/en-us/visualstudio/productinfo/ > vs2013-compatibility-vs > I don't know if that's hard to do, but I strongly suspect that the > existing installers already do that (otherwise supporting newer versions > would likely require separate builds). > > 2013 still runs on Windows 7, should you want that: > https://docs.microsoft.com/en-us/visualstudio/productinfo/ > vs2013-sysrequirements-vs > > According to https://www.postgresql.org/download/windows/ > the available binaries already effectively restrict windows support: > > EDB installers, for 10, restrict to: > 64 Bit Windows: 2016, 2012 R2 & R1, 2008 R2, 7, 8, 10 > 32 Bit Windows: 2008 R1, 7, 8, 10 > > BIGSQL to: Windows 10 and Windows Server 2012. > > Of those 2013 only doesn't run on 2008 R1 anymore. Which still can be > targeted from the newer windows versions. > > > It'd be good to get confirmation that the windows binaries / installers > are indeed built on newer platforms than the oldest supported version. > > We build windows binaries (>=9.3) on Windows 7 and Windows Server 2012 R2. For 9.3, the Visual Studio version is 2010 and for 9.4 and v10, we use 2013. For v11, we use 2017. > Random observation: http://www.openscg.com/bigsql/postgresql/installers/ > seems to indicate that packages aren't updated anymore. While it says > "(09-Aug-18)" besides the major versions, it does not actually in fact > have the last set of minor releases. I suspect that's related to > openscg's acquisition by amazon? Either they need to catch up, or we > need to take down the page and probably alert people about that fact. > > Greetings, > > Andres Freund > -- Sandeep Thakkar
Re: master fails to build on Windows
On Fri, May 18, 2018 at 5:19 PM, John Naylor <jcnay...@gmail.com> wrote: > On 5/18/18, Sandeep Thakkar <sandeep.thak...@enterprisedb.com> wrote: > > Hi > > > > I was building the sources I got from https://www.postgresql.org/ > > ftp/snapshot/dev/ on Windows x64 and got the whole bunch of errors > > like "*Cannot > > open include file: 'catalog/pg_type_d.h"* , *"Cannot open include file: > > 'catalog/pg_tablespace_d.h'" . *I've attached the log. > > I'm thinking the include/catalog/pg_*_d.h headers got dist-cleaned > when creating the snapshot, and the build script doesn't know to copy > them over. If you're able to test, does the attached patch fix the > issue? (This may not be the right permanent fix, but hopefully it will > confirm my suspicion) > > yes, the patch fixes the issue. Thanks. > -John Naylor > -- Sandeep Thakkar EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: MSVC builld of 9.5.12 is broken?
Hi Magnus On Tue, Feb 27, 2018 at 6:05 PM, Magnus Hagander <mag...@hagander.net> wrote: > On Tue, Feb 27, 2018 at 11:53 AM, Victor Wagner <vi...@wagner.pp.ru> > wrote: > >> On Tue, 27 Feb 2018 11:43:34 +0100 >> Magnus Hagander <mag...@hagander.net> wrote: >> >> > On Tue, Feb 27, 2018 at 11:27 AM, Victor Wagner <vi...@wagner.pp.ru> >> > wrote: >> > >> > > Hello, hackers. >> > > >> > > I've tried to build last state of REL9_5_STABLE branch (commit >> > > 1f19e46124eee8c6a54834) and under Win32 encountered following >> > > errors: >> > > >> [skip] >> > >> > It's also interesting to note that this did not break in HEAD, 10 or >> > 9.6. And none of those actually have the SCRIPTS_COMMON code. >> >> It seems that it early stages of 9.6 cycle there was another approach >> taken to improve readability of this Makefile - just all common code >> put into one C file. So there is no need for SCRIPTS_COMMON variable, >> because its name is longer than name of common.o which would be its sole >> contents. >> >> > I'm unsure why this was introduced in 9.5 and earlier, but not in the >> > newer ones. This smells like a possible backpatch mistake, in which >> > case that part should probably be backed out of the old branches >> > rather than teaching mkvcbuild about it. >> >> Note that said commit (91f3ffc5249) is not limited to rearranging >> makefile. It also changes a lot into C code itself. So it is not a >> question of reverting commit - it is making new commit, which reverts >> changes in just one file. > > > Oh, I missed that. > > I think we should revert *just the changes to the Makefile*, and of course > leave the rest of the comimt. Can you confirm if that fixes the problem? > > That fixes some of the errors but the following errors is still seen: common.obj : error LNK2019: unresolved external symbol _fmtQualifiedId referenced in function _appendQualifiedRelation [D:\pginstaller.auto\postgres.windows\createlang.vcxproj] common.obj : error LNK2019: unresolved external symbol _appendStringLiteralConn referenced in function _appendQualifiedRelation [D:\pginstaller.auto\postgres.windows\createlang.vcxproj] .\Release\createlang\createlang.exe : fatal error LNK1120: 2 unresolved externals [D:\pginstaller.auto\postgres.windows\createlang.vcxproj] "D:\pginstaller.auto\postgres.windows\pgsql.sln" (default target) (1) -> "D:\pginstaller.auto\postgres.windows\droplang.vcxproj" (default target) (95) -> common.obj : error LNK2019: unresolved external symbol _fmtQualifiedId referenced in function _appendQualifiedRelation [D:\pginstaller.auto\postgres.windows\droplang.vcxproj] common.obj : error LNK2019: unresolved external symbol _appendStringLiteralConn referenced in function _appendQualifiedRelation [D:\pginstaller.auto\postgres.windows\droplang.vcxproj] .\Release\droplang\droplang.exe : fatal error LNK1120: 2 unresolved externals [D:\pginstaller.auto\postgres.windows\droplang.vcxproj] "D:\pginstaller.auto\postgres.windows\pgsql.sln" (default target) (1) -> "D:\pginstaller.auto\postgres.windows\pg_isready.vcxproj" (default target) (100) -> common.obj : error LNK2019: unresolved external symbol _fmtQualifiedId referenced in function _appendQualifiedRelation [D:\pginstaller.auto\postgres.windows\pg_isready.vcxproj] common.obj : error LNK2019: unresolved external symbol _appendStringLiteralConn referenced in function _appendQualifiedRelation [D:\pginstaller.auto\postgres.windows\pg_isready.vcxproj] .\Release\pg_isready\pg_isready.exe : fatal error LNK1120: 2 unresolved externals [D:\pginstaller.auto\postgres.windows\pg_isready.vcxproj] -- > -- > Magnus Hagander > Me: https://www.hagander.net/ <http://www.hagander.net/> > Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/> > -- Sandeep Thakkar EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
