Re: 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,
John

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(at)postnewspapers(dot)com(dot)au]
Sent: Saturday, October 16, 2010 9:28 PM
To: Rob Sargent
Cc: Turner, John J; pgsql-general(at)postgresql(dot)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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us

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(at)2ndquadrant(dot)com]
Sent: Sunday, October 17, 2010 10:47 PM
To: Turner, John J
Cc: Craig Ringer; Rob Sargent; pgsql-general(at)postgresql(dot)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(at)2ndQuadrant(dot)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

Greg Smith <greg(at)2ndquadrant(dot)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(at)2ndQuadrant(dot)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(at)postnewspapers(dot)com(dot)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(at)postnewspapers(dot)com(dot)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(at)postnewspapers(dot)com(dot)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/