[GENERAL] Problems building from source

2010-06-30 Thread Bidski
Hi all,

I recently had some problems with a pre-built version of PostgreSQL and so I 
decided to try and build my own copy from source, but have run into even more 
problems.

I downloaded a copy of the source, unpacked it into a directory and had a quick 
look at the possible configure options (./configure --help) just to see if 
anything specific caught my eye. The only thing I saw was --with-gnu-ld. So I 
ran configure in the postgresql src root directory as ./configure --with-gnu-ld 
--prefix=/mingw. I got as far as the zlib checks when configure told me that I 
didnt have zlib installed (a quick look at my files confirmed this), so I went 
to www.zlib.net and downloaded version 1.2.5 (this appears to be the latest), I 
then built and installed this. Running configure again (with the same options) 
gave me a wonderful error.

configure: error: zlib version is too old
Use --without-zlib to disable zlib support.

How can the latest version be too old? Seeing this, I uninstalled that 
version and went in search of other versions. The versions I found may not have 
been newer (may have been older) but I tried them anyways, all with the same 
results, apparently all versions were too old. The other versions I found were 
on the MinGW/MSYS download site (http://sourceforge.net/projects/mingw/files/), 
I tried the most recent versions listed on there.

Faced with that, I then changed my configure line to be ./configure 
--prefix=/mingw --with-gnu-ld --without-zlib (who needs zlib anyways, right?). 
Now I was thinking that surely this would be the end of it and I would soon 
have a fully built version of PostgreSQL  sadly not. I now get this 
error.

checking for atexit... yes
checking test program... failed
configure: error:
Could not execute a simple test program.  This may be a problem
related to locating shared libraries.  Check the file 'config.log'
for the exact reason.

And now I have no idea. I had a look at config.log and to find this.

configure:21835: checking for atexit
configure:21891: gcc -qlanglvl=extc89 -o conftest.exe -O2 -Wall 
-Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement 
-Wendif-labels -fno-strict-aliasing -fwrapv  -I./src/include/port/win32 
-DEXEC_BACKEND  -Wl,--allow-multiple-definition  conftest.c  >&5
gcc.exe: unrecognized option '-qlanglvl=extc89'
configure:21898: $? = 0
configure:21920: result: yes
configure:23234: checking test program
configure:23254: gcc -qlanglvl=extc89 -o conftest.exe -O2 -Wall 
-Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement 
-Wendif-labels -fno-strict-aliasing -fwrapv  -I./src/include/port/win32 
-DEXEC_BACKEND  -Wl,--allow-multiple-definition  conftest.c  >&5
gcc.exe: unrecognized option '-qlanglvl=extc89'
configure:23258: $? = 0
configure:23264: ./conftest.exe
./configure: line 23266: ./conftest.exe: Invalid argument
configure:23268: $? = 126
configure: program exited with status 126
configure: failed program was:

Having a look at line 23266 of configure and Im lost (never could understand 
those things).

Can anyone tell me what is going on here? I have built other libraries/packages 
with this toolchain (wxWidgets, xerces-c, boost), so I dont think it is broken.



Some system info.

OS: Windows 7 64-bit

MSYS ver: 1.0.14

MinGW ver: 4.5.0

Make ver: GNU make 3.81

If it matters . My IDE is Eclipse Galileo and I am compiling my project 
using the MinGW toolchain.



If you need any more info just let me know.



Regards

Bidski


Re: [GENERAL] Problems building from source

2010-06-30 Thread Bidski

"Magnus Hagander"  writes:

More likely, it's not finding the right one. Probably it's picking up
some completely different version of it because it's earlier in the
search path.


Here is the start of my PATH environment variable.

   c:\msys\1.0\bin;C:\mingw\bin;C:\mingw\lib;

If it is finding something else, its not looking in my PATH variable for it.


64-bit PostgreSQL builds isn't - it "should just work", but I don't
believe anybody has ever tried it. But this error shows a much more
fundamental problem than the PostgreSQL code, and you need to get that
solved first.


As I said, I have built other packages/libraries (both built the 
library/package itself AND compiled/linked it into my own program and run it 
successfully) with my current set up, so if there is something wrong with 
the toolchain then it is only showing its face because PostgreSQL is doing 
something that the other packages weren't doing. Honestly, I think that is 
enough to say that MinGW/MSYS can run on 64 bit systems and if PostgreSQL is 
only at the stage of "should just work" that there might be a bigger problem 
than my toolchain at play here.



Any particular reason why you don't want to build with the supported
toolset, which is the Microsoft (free) compilers? (See
http://www.postgresql.org/docs/9.0/static/install-win32-full.html)


I am building with my current toolset simply because it appears to be 
working and it is already set up and I would rather not have to go through 
the hassle of having to set up another toolset.


Regards
Bidski




--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general