Thread: installing from source in Windows
I have MinGW installed and I’ve unpacked the pg 9.0 source files which now reside in the following path:
· C:\Program Files\postgresql-9.0.0
In Chapter 15.5 of the 9.0 manual, the installation procedure basically begins by instructing me to run ./configure
This command does not work.
Much appreciated if someone could point me in the right direction or clue me in to what I need in order to run the configuration script.
Thanks,
No at all familiar with MinGW, but I've done some "./configure"s in my time. ./configure scripts 1) check to see what the local build environment contains and 2) which special feature you wish to toggle. But the pretty much assume a unix-like env. Could you put cygwin on rather than just mingw? Turner, John J wrote: > > I have MinGW installed and I’ve unpacked the pg 9.0 source files which > now reside in the following path: > > · C:\Program Files\postgresql-9.0.0 > > In Chapter 15.5 of the 9.0 manual, the installation procedure > basically begins by instructing me to run_ ./configure_ > > This command does not work. > > Much appreciated if someone could point me in the right direction or > clue me in to what I need in order to run the configuration script. > > Thanks, > > John >
On 10/17/2010 12:25 AM, Rob Sargent wrote: > No at all familiar with MinGW, but I've done some "./configure"s in my > time. > > ./configure scripts 1) check to see what the local build environment > contains and 2) which special feature you wish to toggle. > > But the pretty much assume a unix-like env. Could you put cygwin on > rather than just mingw? While I can't speak for PostgreSQL specifically, msys rather than cygwin is typically used for most autotools-based builds of software on Windows. Personally I'd recommend that the OP just grab Visual Studio Express Edition and/or the Windows SDK and compile PostgreSQL that way. See the instructions here: http://developer.postgresql.org/pgdocs/postgres/install-windows-full.html It's astonishingly easy for a Windows build of any kind, let alone of a portable autotools-based open source database. -- Craig Ringer
Yup - after hunting around a bit I realized MSYS was missing, so I installed it. Good news: I now have a Bash interface and ./configure ran successfully Bad news: Now the install process bombs out when I attempt to "make" (it gets Error 1 and Error 2 and backs out of the /c/program files/postgresql-9.0.0/src directory) I'm reluctant at this point to wipe out my MinGW and MSYS and start from scratch with Windows SDK and/or VS-ee... Any insight or advice on this subsequent "make" stumbling block would be most appreciated. Thanks, John -----Original Message----- From: Craig Ringer [mailto:craig@postnewspapers.com.au] Sent: Saturday, October 16, 2010 9:28 PM To: Rob Sargent Cc: Turner, John J; pgsql-general@postgresql.org Subject: Re: [GENERAL] installing from source in Windows On 10/17/2010 12:25 AM, Rob Sargent wrote: > No at all familiar with MinGW, but I've done some "./configure"s in my > time. > > ./configure scripts 1) check to see what the local build environment > contains and 2) which special feature you wish to toggle. > > But the pretty much assume a unix-like env. Could you put cygwin on > rather than just mingw? While I can't speak for PostgreSQL specifically, msys rather than cygwin is typically used for most autotools-based builds of software on Windows. Personally I'd recommend that the OP just grab Visual Studio Express Edition and/or the Windows SDK and compile PostgreSQL that way. See the instructions here: http://developer.postgresql.org/pgdocs/postgres/install-windows-full.htm l It's astonishingly easy for a Windows build of any kind, let alone of a portable autotools-based open source database. -- Craig Ringer
Turner, John J wrote: > Bad news: Now the install process bombs out when I attempt to "make" > (it gets Error 1 and Error 2 and backs out of the /c/program > files/postgresql-9.0.0/src directory) FWIW, it works for me. "Error X" being too little to guess anything, maybe you should paste here the last couple of pages of output you get from make. Best regards, -- Daniel PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org
Bad news: Now the install process bombs out when I attempt to "make"
(it gets Error 1 and Error 2 and backs out of the /c/program
files/postgresql-9.0.0/src directory)
This is the full log of what happens when I run make:
$ make
make -C src all
make[1]: Entering directory `/c/program
files/postgresql-9.0.0/src'
make -C port all
make[2]: Entering directory `/c/program files/postgresql-
9.0.0/src/port'
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration- after-statement
-Wendif-labels -fno-strict-aliasing -fwrapv -I../../src/port -
DFRONTEND -I../..
/src/include -I./src/include/port/win32 -DEXEC_BACKEND "-
I../../src/include/port/win32" -c -o crypt.o crypt.c
In file included from crypt.c:44:
../../src/include/c.h:284:2: #error must have a working 64-bit
integer datatype
In file included from ../../src/include/c.h:851,
from crypt.c:44:
../../src/include/port.h:369:1: warning: "fseeko" redefined
In file included from ../../src/include/c.h:90,
from crypt.c:44:
../../src/include/pg_config_os.h:208:1: warning: this is the
location of the previous definition
In file included from ../../src/include/c.h:851,
from crypt.c:44:
../../src/include/port.h:370:1: warning: "ftello" redefined
In file included from ../../src/include/c.h:90,
from crypt.c:44:
../../src/include/pg_config_os.h:209:1: warning: this is the
location of the previous definition
make[2]: *** [crypt.o] Error 1
make[2]: Leaving directory `/c/program files/postgresql-
9.0.0/src/port'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/c/program
files/postgresql-9.0.0/src'
make: *** [all] Error 2
Thanks,
John
On 10/18/2010 06:18 AM, Turner, John J wrote: > ../../src/include/c.h:284:2: #error must have a working 64-bit > integer datatype There's your problem. "configure" didn't detect support for 64-bit integers in your compiler, causing the build to fail at: 00276 #ifndef HAVE_INT64 00277 typedef long long int int64; 00278 #endif 00279 #ifndef HAVE_UINT64 00280 typedef unsigned long long int uint64; 00281 #endif 00282 #else 00283 /* neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 */ 00284 #error must have a working 64-bit integer datatype 00285 #endif in c.h I've never done a mingw build of PostgreSQL on windows, as I see little point in doing so when the MSVC++ compiler native to the platform is supported, so I can't offer you much advice here. If you upload your config.log somewhere people can get to it, that might help. Without that it's hard to know why configure rejected the compiler's 64-bit int data type. -- Craig Ringer
Turner, John J wrote: > I'm reluctant at this point to wipe out my MinGW and MSYS and start from > scratch with Windows SDK and/or VS-ee... > Well, you should probably get over that, because all of the official builds of 9.0 don't really care about supporting MinGW anymore. See http://www.postgresql.org/docs/9.0/interactive/install-windows.html for notes on this. I wouldn't be surprised to find the capability to build with MinGW is broken in various ways now, because it doesn't get tested anymore that I'm aware of. I gave up on that toolchain the minute the newer Visual Studio alternative was available, and tossing out MinGW for this purpose has been nothing but an improvement for me. -- Greg Smith, 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services and Support www.2ndQuadrant.us
On 10/18/2010 11:28 AM, Turner, John J wrote: > .. I thought it was worth a shot to try building from source with > MinGW/MSYS to get the pgxs files... but apparently not -- especially > since I'm on Windows XP 32-bit platform (hence the issue with 64-bit > datatypes bombing out during make, I presume) No. 64-bit integers should work fine on a 32-bit platform and a 32-bit compiler. Please post the "config.log" file generated by configure somewhere, so it can be examined. If you like, compress it and email it to me directly, not to the list, and I'll see if I can tell what's going on, though I don't use mingw and msys much. In any case, if it's structured appropriately (I haven't checked) you should also be able to build the temporal package as a contrib module, by putting it in the postgresql source tree's contrib/ directory and compiling PostgreSQL with msvc. It was trivial for me to add a custom extension I was writing using that method. -- Craig Ringer
Hmmm.. seems like I'm in a dandy of a catch-22 On an earlier post (http://archives.postgresql.org/pgsql-general/2010-09/msg01043.php) I was inquiring about trying to add in Jeff Davis' temporal extension package available from pgFoundry. Based on the facts that: 1) the temporal package installs by using pgxs and 2) pgxs doesn't work with the Windows VC++ build .. I thought it was worth a shot to try building from source with MinGW/MSYS to get the pgxs files... but apparently not -- especially since I'm on Windows XP 32-bit platform (hence the issue with 64-bit datatypes bombing out during make, I presume) So unless I've totally misunderstood, if I go the VC++ route, I can't get pgxs, right? And getting that tool to build/add-in extensions with was my goal in the first place... Thanks, John -----Original Message----- From: Greg Smith [mailto:greg@2ndquadrant.com] Sent: Sunday, October 17, 2010 10:47 PM To: Turner, John J Cc: Craig Ringer; Rob Sargent; pgsql-general@postgresql.org Subject: Re: [GENERAL] installing from source in Windows Turner, John J wrote: > I'm reluctant at this point to wipe out my MinGW and MSYS and start from > scratch with Windows SDK and/or VS-ee... > Well, you should probably get over that, because all of the official builds of 9.0 don't really care about supporting MinGW anymore. See http://www.postgresql.org/docs/9.0/interactive/install-windows.html for notes on this. I wouldn't be surprised to find the capability to build with MinGW is broken in various ways now, because it doesn't get tested anymore that I'm aware of. I gave up on that toolchain the minute the newer Visual Studio alternative was available, and tossing out MinGW for this purpose has been nothing but an improvement for me. -- Greg Smith, 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services and Support www.2ndQuadrant.us
Greg Smith <greg@2ndquadrant.com> writes: > Well, you should probably get over that, because all of the official > builds of 9.0 don't really care about supporting MinGW anymore. See > http://www.postgresql.org/docs/9.0/interactive/install-windows.html for > notes on this. I wouldn't be surprised to find the capability to build > with MinGW is broken in various ways now, because it doesn't get tested > anymore that I'm aware of. Buildfarm member narwhal is supposedly testing on mingw. regards, tom lane
On 10/18/2010 12:29 PM, Turner, John J wrote: > > Craig, thanks for having a go at it - and thanks for all the help thus > far! OK. According to your config.log, configure tests "long int" and determines it's only 32 bits, so tries "long long int" and determines that it's 64 bits wide. So there is a 64-bit type available. This sets HAVE_LONG_LONG_INT_64=1 . That should cause this test in c.h to pass: #ifdef HAVE_LONG_INT_64 // blah blah #elif defined(HAVE_LONG_LONG_INT_64) // blah blah #else /* neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 */ #error must have a working 64-bit integer datatype #endif ... but the error you're getting suggests that it doesn't. Have you re-tried all this on a clean source tree, running under the msys shell from start to finish? -- Craig Ringer
Craig Ringer wrote: > Have you re-tried all this on a clean source tree, running under the > msys shell from start to finish? A handy thing to know is that running "make maintainer-clean" in the source code tree will clean out all artifacts from any previous build attempt. -- Greg Smith, 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services and Support www.2ndQuadrant.us Author, "PostgreSQL 9.0 High Performance" Pre-ordering at: https://www.packtpub.com/postgresql-9-0-high-performance/book
I retried after make maintainer-clean and same problem - Here's a question: is my source download getting mangled by unpacking with WinZip instead of gzip? I'm beginning to suspect so. I don't have gzip installed. And frankly, I don't know how - the GNU site doesn't seem to have a step-by-step.. Anyway, thought I'd throw that out there as a possible cause for a failed source build... Thanks, John -----Original Message----- From: Craig Ringer [mailto:craig@postnewspapers.com.au] Sent: Monday, October 18, 2010 1:39 AM To: Turner, John J; List, Postgres Subject: Re: [GENERAL] installing from source in Windows On 10/18/2010 12:29 PM, Turner, John J wrote: > > Craig, thanks for having a go at it - and thanks for all the help thus > far! OK. According to your config.log, configure tests "long int" and determines it's only 32 bits, so tries "long long int" and determines that it's 64 bits wide. So there is a 64-bit type available. This sets HAVE_LONG_LONG_INT_64=1 . That should cause this test in c.h to pass: #ifdef HAVE_LONG_INT_64 // blah blah #elif defined(HAVE_LONG_LONG_INT_64) // blah blah #else /* neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 */ #error must have a working 64-bit integer datatype #endif ... but the error you're getting suggests that it doesn't. Have you re-tried all this on a clean source tree, running under the msys shell from start to finish? -- Craig Ringer
On 19/10/2010 5:58 AM, Turner, John J wrote: > Here's a question: is my source download getting mangled by unpacking > with WinZip instead of gzip? I doubt it. I use 7-zip on Windows without problems. You certainly don't need to use gzip and GNU tar. I'm pretty puzzled about why c.h isn't seeing the macro definitions set by configure - but not puzzled enough to want to suffer though msys/mingw/autohell on Windows when the VC build "just works". -- Craig Ringer Tech-related writing at http://soapyfrogs.blogspot.com/
I began to suspect my version of WinZip was lousing up the pg source files when it dropped files from a zlib.tar I was trying to install. So, I installed 7-zip and unpacked the pg source with that.. - I ran ./configure --without-zlib Then: make world Success! (then: make install-world) So, now it's a hot mess of something - looks a far cry from the binary version I originally downloaded, but supposedly it's installed Pgxs looks to be in there too deep in a test path... I think I'll need to sleep on it before I can make heads or tails of the installed tree -- but tremendous thanks for all the help! I'd be lost otherwise. Cheers, John -----Original Message----- From: Craig Ringer [mailto:craig@postnewspapers.com.au] Sent: Monday, October 18, 2010 8:20 PM To: Turner, John J Cc: List, Postgres Subject: Re: [GENERAL] installing from source in Windows On 19/10/2010 5:58 AM, Turner, John J wrote: > Here's a question: is my source download getting mangled by unpacking > with WinZip instead of gzip? I doubt it. I use 7-zip on Windows without problems. You certainly don't need to use gzip and GNU tar. I'm pretty puzzled about why c.h isn't seeing the macro definitions set by configure - but not puzzled enough to want to suffer though msys/mingw/autohell on Windows when the VC build "just works". -- Craig Ringer Tech-related writing at http://soapyfrogs.blogspot.com/
On 19/10/10 11:58, Turner, John J wrote: > I began to suspect my version of WinZip was lousing up the pg source > files when it dropped files from a zlib.tar I was trying to install. Hmm, ok. Thanks for the heads-up, then. "Winzip mangles tar archives" goes into the list of possible fault causes... > So, now it's a hot mess of something - looks a far cry from the binary > version I originally downloaded, but supposedly it's installed Yep. It's really quite easy to use the installs built from source or obtained as a binary zip, thankfully. You use initdb to create a data directory, then pg_ctl to start the server once initdb has run. initdb even prints out the pg_ctl command to use. Installing it as a Windows service is a bit trickier, though. -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/
Apologies in advance as I'm compelled to resurrect this topic: I've posted my latest issue to the novice list (http://archives.postgresql.org/pgsql-novice/2010-10/msg00137.php) .. to no avail And just to re-state the issue - "make check" doesn't work as it fails to start the Postmaster (within 60 seconds). After doing some homework, my hunch is that I need to translate "su" type Unix commands into something the MSYS bash interface can understand in order to be running the tests under a proper "unprivileged" user account... I tried running the bash using several different variations of the "runas" command, again to no avail. So I'll be much obliged for any further advice or suggestions - even if only to let me know whether I might be way off base or need to do some more homework. Thanks, John -----Original Message----- From: Craig Ringer [mailto:craig@postnewspapers.com.au] Sent: Tuesday, October 19, 2010 12:23 AM To: Turner, John J Cc: List, Postgres Subject: Re: [GENERAL] installing from source in Windows On 19/10/10 11:58, Turner, John J wrote: > I began to suspect my version of WinZip was lousing up the pg source > files when it dropped files from a zlib.tar I was trying to install. Hmm, ok. Thanks for the heads-up, then. "Winzip mangles tar archives" goes into the list of possible fault causes... > So, now it's a hot mess of something - looks a far cry from the binary > version I originally downloaded, but supposedly it's installed Yep. It's really quite easy to use the installs built from source or obtained as a binary zip, thankfully. You use initdb to create a data directory, then pg_ctl to start the server once initdb has run. initdb even prints out the pg_ctl command to use. Installing it as a Windows service is a bit trickier, though. -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/