Sorry, here is my message for the mailing list.
> ---------- Ursprüngliche Nachricht ----------
> Von: "Lars Ewald (web.de)" <l(dot)ewald-web(at)lars-ewald(dot)de>
> An: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Datum: 14. Juli 2014 um 17:23
> Betreff: Re: [BUGS] Compile fails on AIX 6.1
>
> Hello Tom,
>
> > >> PPC what exactly?
>
> PowerPC_POWER5:
> System Model: IBM,9110-51A
> Machine Serial Number: *********
> Processor Type: PowerPC_POWER5
> Processor Implementation Mode: POWER 5
> Processor Version: PV_5_2
> Number Of Processors: 4
> Processor Clock Speed: 1499 MHz
> CPU Type: 64-bit
> Kernel Type: 64-bit
> LPAR Info: 1 **********
> Memory Size: 7936 MB
> Good Memory Size: 7936 MB
> Platform Firmware level: SF240_418
> Firmware Version: IBM,SF240_418
> Full Core: false
>
>
>
> Would it help to use a POWER7 system as followed?
> System Model: IBM,8202-E4C
> Machine Serial Number: *********
> Processor Type: PowerPC_POWER7
> Processor Implementation Mode: POWER 7
> Processor Version: PV_7_Compat
> Number Of Processors: 4
> Processor Clock Speed: 3024 MHz
> CPU Type: 64-bit
> Kernel Type: 64-bit
> LPAR Info: 15 ************
> Memory Size: 8192 MB
> Good Memory Size: 8192 MB
> Platform Firmware level: AL740_126
> Firmware Version: IBM,AL740_100
> Full Core: false
>
>
> > Still, configure should have caught that. Does configure end up
> > defining HAVE_PPC_LWARX_MUTEX_HINT in src/include/pg_config.h?
>
> Yes, I HAVE_PPC_LWARX_MUTEX_HINT was defined.
>
> [...]
> /* Define to 1 if you have the POSIX signal interface. */
> #define HAVE_POSIX_SIGNALS /**/
>
> /* Define to 1 if the assembler supports PPC's LWARX mutex hint bit. */
> #define HAVE_PPC_LWARX_MUTEX_HINT 1
>
> /* Define to 1 if you have the `pstat' function. */
> /* #undef HAVE_PSTAT */
>
> /* Define to 1 if the PS_STRINGS thing exists. */
> /* #undef HAVE_PS_STRINGS */
> [...]
>
>
>
> > Assuming that HAVE_PPC_LWARX_MUTEX_HINT is *not* getting set,
> > I'd suggest commenting out the #define for USE_PPC_LWSYNC in
> > pg_config_manual.h and see if it gets better. If that is the
> > answer then I guess we will need a configure-time test for lwsync
> > support after all.
>
> Commenting out USE_PPC_LWSYNC did not help. Also, commenting
> USE_PPC_LWSYNC out and set HAVE_PPC_LWARX_MUTEX_HINT to "0", was
> not successful.
>
>
> Best regards
> Lars
>
>
>
> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> hat am 11. Juli 2014 um 16:55 geschrieben:
> >
> >
> > [ please keep the mailing list cc'd ]
> >
> > "Lars Ewald (web.de)" <l(dot)ewald-web(at)lars-ewald(dot)de> writes:
> > > Thank you for answering very fast.
> >
> > >> PPC what exactly?
> >
> > > chrp with 64-bit.
> > > MACHINE_ARCHITECTURE: chrp
> > > HARDWARE_BITMODE: 64
> >
> > > Do you need further information regarding the system?
> >
> > Yes, please; CHRP is pretty non-specific as regards the processor
> > generation. However, it's probably *old* since CHRP wasn't too
> > successful according to Wikipedia. If the CPU predates POWER6 or
> > thereabouts, then lack of LWARX hint support in the assembler
> > wouldn't be surprising.
> >
> > Still, configure should have caught that. Does configure end up
> > defining HAVE_PPC_LWARX_MUTEX_HINT in src/include/pg_config.h?
> >
> > Hmm ... looking at s_lock.h some more, I wonder if maybe it's
> > LWSYNC and not LWARX that's causing the problem. We currently
> > set USE_PPC_LWSYNC for any PPC64 build (see pg_config_manual.h).
> > IIRC we knew that there were a few machines for which that heuristic
> > would fail, but we didn't think anybody would be using Postgres
> > on them.
> >
> > Assuming that HAVE_PPC_LWARX_MUTEX_HINT is *not* getting set,
> > I'd suggest commenting out the #define for USE_PPC_LWSYNC in
> > pg_config_manual.h and see if it gets better. If that is the
> > answer then I guess we will need a configure-time test for lwsync
> > support after all.
> >
> > >> I think the odds are pretty high that the problem here is that we tried
> > >> to
> > >> use the "mutex hint" option in our PPC spinlock assembly code, and the
> > >> system's assembler doesn't recognize that.
> >
> > > Would it help to use another compiler, e.g. XL C?
> >
> > It'd be worth trying if you have another one at hand, but it's
> > hard to say what the results would be.
> >
> > Note that there's a question here not only as to whether it will
> > build, but whether it will run on your hardware. I'd definitely
> > try "make check" before believing that you have a working build.
> >
> > >> However, we only try to use that option after the configure script has
> > >> confirmed that the syntax is
> > >> accepted, so it's not real clear how you got this result. Perhaps you
> > >> tried to change compilers without redoing the configure run?
> >
> > > No. I did not change the compiler. By the way, I always run "make clean"
> > > and
> > > then re"configure"
> > > to recompile the code.
> >
> > That might be good enough, but personally I always do "make distclean"
> > before reconfiguring.
> >
> > regards, tom lane
>