The system and compiler are patched with the latest fix packs from IBM, and the compiler version is the latest available.
The compiler is functional (eg: I was able to compile successfuly 64 bit versions other software such as Apache 2.2.11, emacs 22.3, vim 7.2, openssl-0.9.8j and so on, all with similar flags).
So if this is a compiler bug, it certainly isn't an obvious one. I'll dig deeper to see how I can convince configure to use -qnooptimize.
The first build was using default options for xlC_r (the default for all IBM compilers is -qnooptimize). ./configure seems to override this:
When I've used the build farm scripts, configure gives xlC_r these flags:
configure:7117: xlC_r -q64 -o conftest -O2 -qmaxmem=16384 -qsrcmsg -qlonglong -g -I/opt/freeware/include/libxml2 -L/opt/freeware/lib conftest.c -lm >&5
1506-396 (W) Option -qlonglong is incompatible with option -qlanglvl=extc99 and is ignored.
ld: 0711-317 ERROR: Undefined symbol: .setproctitle
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
configure:7123: $? = 8
I'll try a 32 bit build too.
On Mon, Feb 9, 2009 at 8:58 AM, Tom Lane
<tgl@sss.pgh.pa.us> wrote:
Mihai Criveti <
cmihai@boreas.ro> writes:
> creating system views ... WARNING: could not dump unrecognized node type:
> 650
> WARNING: could not dump unrecognized node type: 650
> WARNING: could not dump unrecognized node type: 650
> WARNING: could not dump unrecognized node type: 650
> WARNING: could not dump unrecognized node type: 650
> WARNING: could not dump unrecognized node type: 650
> WARNING: could not dump unrecognized node type: 650
> WARNING: could not dump unrecognized node type: 650
> WARNING: could not dump unrecognized node type: 650
> WARNING: could not dump unrecognized node type: 650
> WARNING: could not dump unrecognized node type: 650
> FATAL: badly formatted node string "} {} {} {} {} {} {} {} {} {} {})"...
My, that's interesting. A look at nodes.h shows that 650 == T_Value,
which simply should not ever occur as a live node type. Unless my grep
is missing something, T_Value itself is never directly referenced
anywhere in the 8.3 source code. There are five occurrences of
makeNode(Value) but each of them immediately overwrites the node type
field with another type code such as T_Integer or T_String.
Not to put too fine a point on it, but I'm thinking "compiler bug".
You might try a build with the optimization level backed off to see
if the problem goes away.
regards, tom lane
--
Criveti Mihai
http://unixsadm.blogspot.com