Обсуждение: Issues with compiling libpq 9.1.2 with Visual C++
OS: Windows 10
Toolset: vc141 (Visual Studio 2017)
I’m having trouble compiling version 9.1.2 of libpq with Visual C++. The reason that I want this particular version is because it’s the one included with GDAL version 2.1.3 from GISinternals.com. To be specific, I pulled commit cfd8cf37d20be715e4bb9e382844c79556516824 from GitHub.
What I’m doing is running a powershell script with the following command (of course, I’ve already run the batch-file included with Visual Studio which sets all the relevant PATH environment variables needed to compile with Visual C++):
nmake /f “win32.mak” DEBUG=1 USE_SSL=1 SSL_INC=”$opensslDir\include” SSL_LIB_PATH=”$opensslDir\x86\Debug\lib\”
This first complains that there’s no libpq-dist.rc. Through some googling I found this page: https://pgolub.wordpress.com/2009/04/13/building-postgresql-client-library-using-borland-c-compiler-bcc-under-winxp/ It says to just rename libpq.rc.in. This at least stops the error message, but it then complains about not finding libpqdll.def. That page said that the author solved it by simply finding an old version of that file, which to me sounds like a bad idea and also I’ve been unable to do.
If I run the build again it doesn’t complain about the lack of libpqdll.def and claims that all Win32 files have been built. The static lib *seems* to have been built correctly, but the libpq.dll is 0 kB and there’s no libpqdll.lib, so it clearly fails.
I’m *guessing* that both libpq-dist.rc and libpqdll.def would have been generated by running .\configure. However, when I try doing that it only looks for gcc and cc, but not cl.exe, so it gives the error that there’s “no acceptable C compiler found in $PATH”. I’ve found through Googling around that a lot of other people have .\configure scripts that look for cl.exe as well.
I’m running .\configure like this, btw:
sh .\configure
“sh” is Git Bash.
So,
How do I get libpq-dist.rc and libpqdll.def? (Through .\configure?)
If I have to use .\configure, how do I get it to look for cl.exe?
Thank you.
=?iso-8859-1?Q?Nordstr=F6m_Thomas?= <thomas.nordstrom1@saabgroup.com> writes: > Toolset: vc141 (Visual Studio 2017) > I'm having trouble compiling version 9.1.2 of libpq with Visual C++. That's going to be ... exciting. I don't think we promise to support VS2017 even yet; the latest VS patches I can remember seeing were for VS2015. And 9.1.2 came out in 2011, so there wasn't support for anything newer than VS2008 at the time. > The reason that I want this particular version is because it's the one included with GDAL version 2.1.3 from GISinternals.com.To be specific, I pulled commit cfd8cf37d20be715e4bb9e382844c79556516824 from GitHub. I would not take that as a good reason to use an ancient version of libpq. AFAIK we haven't broken backwards compatibility in libpq, so current versions ought to work just fine with the GDAL version you want to use. > What I'm doing is running a powershell script with the following command (of course, I've already run the batch-file includedwith Visual Studio which sets all the relevant PATH environment variables needed to compile with Visual C++): > nmake /f "win32.mak" DEBUG=1 USE_SSL=1 SSL_INC="$opensslDir\include" SSL_LIB_PATH="$opensslDir\x86\Debug\lib\" The recommended way to build PG under VS is to use the project files we supply. That will wind up building the whole server not just libpq, but it'll still take less time than you've already wasted fighting this tooling version skew. What I'd try doing is building a PG release that claims to support VS2015 (9.6 or later), using the recommended process: https://www.postgresql.org/docs/current/static/install-windows.html Or you could just grab a prebuilt version from our download pages. Then point GDAL at the libpq library from that. regards, tom lane