Re: Fwd: Re: Compile fails on AIX 6.1 - Mailing list pgsql-bugs

Hello Tom,

today I was able to do some tests compiling Postgres on our AIX machine.

And...it worked! :-) Configuring without spinlocks and readline worked fine=
 for
me and did not abort after compiling xlog.o/xlog.c.
Any ideas why it does not work with spinlocks?



Best regards,
Lars

p. s. Compiling against xlC did not work. I think our xlC installation is a=
 bit
curious. :-(





> "Lars Ewald (web.de)" <l.ewald-web@lars-ewald.de> hat am 15. Juli 2014 um
> 18:51 geschrieben:
>=20
>  Sorry, here is my message for the mailing list.
>=20
>   > > ---------- Urspr=C3=BCngliche Nachricht ----------
> >   Von: "Lars Ewald (web.de)" <l.ewald-web@lars-ewald.de>
> >   An: Tom Lane <tgl@sss.pgh.pa.us>
> >   Datum: 14. Juli 2014 um 17:23
> >   Betreff: Re: [BUGS] Compile fails on AIX 6.1
> >=20
> >   Hello Tom,
> >=20
> >   > >> PPC what exactly?
> >=20
> >   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
> >=20
> >=20
> >=20
> >   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
> >=20
> >=20
> >   > Still, configure should have caught that. Does configure end up
> >   > defining HAVE_PPC_LWARX_MUTEX_HINT in src/include/pg_config.h?
> >=20
> >   Yes, I HAVE_PPC_LWARX_MUTEX_HINT was defined.
> >=20
> >   [...]
> >   /* Define to 1 if you have the POSIX signal interface. */
> >   #define HAVE_POSIX_SIGNALS /**/
> >=20
> >   /* Define to 1 if the assembler supports PPC's LWARX mutex hint bit. =
*/
> >   #define HAVE_PPC_LWARX_MUTEX_HINT 1
> >=20
> >   /* Define to 1 if you have the `pstat' function. */
> >   /* #undef HAVE_PSTAT */
> >=20
> >   /* Define to 1 if the PS_STRINGS thing exists. */
> >   /* #undef HAVE_PS_STRINGS */
> >   [...]
> >=20
> >=20
> >=20
> >   > 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.
> >=20
> >   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.
> >=20
> >=20
> >   Best regards
> >   Lars
> >=20
> >=20
> >=20
> >   > Tom Lane <tgl@sss.pgh.pa.us> hat am 11. Juli 2014 um 16:55 geschrie=
ben:
> >   >
> >   >
> >   > [ please keep the mailing list cc'd ]
> >   >
> >   > "Lars Ewald (web.de)" <l.ewald-web@lars-ewald.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 heuristi=
c
> >   > 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 w=
e
> >   > >> tried to
> >   > >> use the "mutex hint" option in our PPC spinlock assembly code, a=
nd
> >   > >> 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 scri=
pt
> >   > >> has
> >   > >> confirmed that the syntax is
> >   > >> accepted, so it's not real clear how you got this result. Perhap=
s 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 distcle=
an"
> >   > before reconfiguring.
> >   >
> >   > regards, tom lane
> >=20
> >  >=20
>=20
>=20