From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mihai Criveti <cmihai(at)boreas(dot)ro>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 64 bit PostgreSQL 8.3.6 build on AIX 5300-09-02-0849 with IBM XL C/C++ 10.1.0.1 - initdb fails (could not dump unrecognized node type: 650) |
Date: | 2009-02-11 08:48:49 |
Message-ID: | 499290F1.5000108@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> So it seems we have a couple of problems here. Using xlc_r or xlC_r
> or adding -q64 to CC (rather than CFLAGS which is where it really
> belongs) will confuse this check.
Correction: Flags that determine the architecture usually belong in CC,
not in CFLAGS.
Test case for when a flag belongs into CC instead of CFLAGS:
To compile a file, you use $(CC) $(CPPFLAGS) $(CFLAGS).
To preprocess a file, you use $(CPP) $(CPPFLAGS), where CPP is usually
$(CC) -E.
If you have a compiler flag that applies for preprocessing, you must put
it into CC.
Another class of flags that is typically put into CC are those selecting
the C standards mode.
> Would it be reasonable to change the test quoted above to
>
> elif test "$PORTNAME" = "aix"; then ...
>
> that is try -qnoansialias anytime the compiler isn't gcc and the
> platform is aix? Is xlc used on any platform other than aix?
That would probably make sense. I think we just never supported xlc_r,
and the threading code rejects a separate thread-safe compiler.
> Also, has anyone got a clue what the switches selected in
> src/template/aix actually do, and whether they still make sense
> for modern AIX versions?
-qmaxmem=16384 is the memory for optimizations (in bytes).
-qsrcmsg prints the affected code line in a compiler error (instead of
just file name and line number).
-qlonglong is clear.
From | Date | Subject | |
---|---|---|---|
Next Message | Matteo Beccati | 2009-02-11 09:22:47 | DISCARD ALL failing to acquire locks on pg_listen |
Previous Message | Markus Wanner | 2009-02-11 08:21:43 | Re: A deprecation policy |