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 <t...@sss.pgh.pa.us> wrote:
> Mihai Criveti <cmi...@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
