Re: Fwd: Re: Compile fails on AIX 6.1

From: "Lars Ewald (web(dot)de)" <l(dot)ewald-web(at)lars-ewald(dot)de>
To: pgsql-bugs(at)postgreSQL(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Fwd: Re: Compile fails on AIX 6.1
Date: 2014-07-25 19:59:56
Message-ID: 1187174843.224799.1406318396067.open-xchange@oxbaltgw13.schlund.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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(dot)ewald-web(at)lars-ewald(dot)de> hat am 15. Juli 2014 um
> 18:51 geschrieben:
>
> 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
> >
> > >
>
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2014-07-25 22:32:48 Re: Fwd: Re: Compile fails on AIX 6.1
Previous Message Sergiy Zuban 2014-07-25 15:21:26 Re: BUG #11032: Prepared transactions do not update pg_last_xact_replay_timestamp() anymore

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-07-25 20:16:25 Re: pg_background (and more parallelism infrastructure patches)
Previous Message Tom Lane 2014-07-25 19:52:12 Re: implement subject alternative names support for SSL connections