Fwd: Re: Compile fails on AIX 6.1

Поиск
Список
Период
Сортировка
От Lars Ewald (web.de)
Тема Fwd: Re: Compile fails on AIX 6.1
Дата
Msg-id 1823346352.314711.1405443099463.open-xchange@oxbaltgw55.schlund.de
обсуждение исходный текст
Ответы Re: Fwd: Re: Compile fails on AIX 6.1  (Rainer Tammer <pgsql@spg.schulergroup.com>)
Re: Fwd: Re: Compile fails on AIX 6.1  ("Lars Ewald (web.de)" <l.ewald-web@lars-ewald.de>)
Список pgsql-bugs
Sorry, here is my message for the mailing list.

> ---------- 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 geschrieben=
:
>  >
>  >
>  > [ 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 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 t=
ried
>  > >> 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 y=
ou
>  > >> tried to change compilers without redoing the configure run?
>  >
>  > > No. I did not change the compiler. By the way, I always run "make cl=
ean"
>  > > 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
>=20

В списке pgsql-bugs по дате отправления:

Предыдущее
От: David Tonhofer
Дата:
Сообщение: Documentation problem: The syntax for "\copy" is just wrong
Следующее
От: jeff@goaldriven.com
Дата:
Сообщение: BUG #10972: string_agg function incorrectly concatenating varying delimiter