Обсуждение: Things I learned about PG8 on AIX5.3 with XLC compiler

Just a short,terse list:

Don't use nondefault optimization. There is something going on
with the code that breaks, runtime, when compiled (which works
fine per se) with higher optimization levels. IPA is a real
difficulty.

Remember to set OBJECT_MODE=64 in OS env!

upgrading m4/autoconf and then configure seems to really help.
(m4 needs __STDC__ to get around "va_list" compilation error)

setting LIBPATH is quite helpful.

RMohan@arbinet.com ("Mohan, Ross") writes:
It would be worthwhile to try to formulate this as a patch to the
FAQ_AIX file.  Probably something like....

PostgreSQL 8 on AIX 5.3, compiled using VisualAge C
------------------------------------------------------

- Use only default optimization.  Higher optimization levels have been
  observed to lead to runtime problems, particularly with IPA

- Be sure to "export OBJECT_MODE=64" to compile in 64 bit mode

- Upgrading m4/autoconf helps with ./configure.

- m4 needs __STDC__ defined in order to avoid "va_list" compilation
  errors.

- Setting LIBPATH (to what???) has proved useful
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://www.ntlug.org/~cbbrowne/sap.html
Rules of the Evil Overlord #78.  "I will not tell my Legions of Terror
"And he must  be taken alive!" The command will be:  ``And try to take
him alive if it is reasonably practical.''"
<http://www.eviloverlord.com/>

:-)

LIBPATH=./usr/local/lib:/local/lib:/lib:/usr/lib:/usr/local/pgsql/lib:/home/app/postgresql-8.0.2/src/port


While I very much wish I had this little list before I started this, I'd
be loathe to consider it the end of the story.  I'd say, maybe, "A Small Subset
of Helpful Things to Consider".

I can get it to compile under all optimization levels (an optimization level
is a bundle of little features...), but on almost all of them, the runtime
breaks ( e.g. at initdb -D  with "...broken node..." errors)


I am going to try to optimize this thing, still. Several things are in the way:


1) Many (many!) uninitialized variables in code. Optimizers don't
    do well with this.

2) Not clear (to me, a nonprogrammer) whether this is GNU C, ANSI C,
    "Postgres" C, or what the overall coding protocol is. This would
    be helpful in dis-assembling the pre-packaged compiler optimization
    bundles, and just picking the compiler flags the code can withstand.

3)  Compilation with profiling/debugging support appears, also, to break
    the runtime. Makes it hard to...erm...debug.


Anyways, tallyho.

-- Ross

p.s. by the way, there is no more "Visual Age" compiler. It's been re-branded
     as XL C/C++.     :-)



-----Original Message-----
From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Chris Browne
Sent: Tuesday, June 07, 2005 3:23 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Things I learned about PG8 on AIX5.3 with XLC compiler


RMohan@arbinet.com ("Mohan, Ross") writes:
It would be worthwhile to try to formulate this as a patch to the FAQ_AIX file.  Probably something like....

PostgreSQL 8 on AIX 5.3, compiled using VisualAge C
------------------------------------------------------

- Use only default optimization.  Higher optimization levels have been
  observed to lead to runtime problems, particularly with IPA

- Be sure to "export OBJECT_MODE=64" to compile in 64 bit mode

- Upgrading m4/autoconf helps with ./configure.

- m4 needs __STDC__ defined in order to avoid "va_list" compilation
  errors.

- Setting LIBPATH (to what???) has proved useful
--
(format nil "~S@~S" "cbbrowne" "acm.org") http://www.ntlug.org/~cbbrowne/sap.html
Rules of the Evil Overlord #78.  "I will not tell my Legions of Terror "And he must  be taken alive!" The command will
be: ``And try to take him alive if it is reasonably practical.''" <http://www.eviloverlord.com/> 

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Mohan, Ross wrote:
> 1) Many (many!) uninitialized variables in code. Optimizers don't
>     do well with this.

Um, what?

> 2) Not clear (to me, a nonprogrammer) whether this is GNU C, ANSI C,
>     "Postgres" C, or what the overall coding protocol is.

Postgres is mostly ANSI C89, with limited use of GNU C extensions (which
should be limited to inside #ifdef __GNUC__ blocks, AFAIK).

-Neil

Neil Conway <neilc@samurai.com> writes:
> Mohan, Ross wrote:
>> 2) Not clear (to me, a nonprogrammer) whether this is GNU C, ANSI C,
>> "Postgres" C, or what the overall coding protocol is.

> Postgres is mostly ANSI C89, with limited use of GNU C extensions (which
> should be limited to inside #ifdef __GNUC__ blocks, AFAIK).

s/mostly/entirely/ and s/should be/are/, please.  If you can identify
specific violations of those coding rules, we are all ears.

BTW, we really really need some more non-gcc compilers in the
buildfarm.  I realized this afternoon that CVS tip is breaking the
perennial bugaboo that gcc does not complain about

    static int foo(...);

    ...

    int foo(...)
    {
        ...
    }

that is omitting "static" from the actual routine definition --- which
plenty of other compilers do complain about; so why don't we have a few
buildfarm members that will yap loud and long about this?

            regards, tom lane