can't compile google-perftools on AIX6.1

[GoogleCodeExporter]

the following is the issue:
1.downloaded gperftools-2.0.tar.gz from  
http://code.google.com/p/gperftools/downloads/list which is updated as Feb 3rd
2.run configure after unzip and unpack, no error produced
3.run gmake and get errors which I put in the attachment gmake.log.zip

os: AIX 6.1 TL6     
gcc: 4.4.6

the config.log and config.h are also i attached.

Original issue reported on code.google.com by happysa...@gmail.com on 18 Mar 2012 at 8:04

Attachments:

• config.h.zip
• config.log.zip
• gmake.log.zip

[GoogleCodeExporter]

Since I don't have access to a machine running AIX I am not going to be of much 
use here. Any progress on your end? 

Original comment by chapp...@gmail.com on 3 May 2012 at 2:56

[GoogleCodeExporter]

Ok so I took a closer look at things here and found this:

gperftools-2.0/src/malloc_hook-inl.h
 56 template<typename PtrT>
 57 class AtomicPtr {
 58  public:
 59   COMPILE_ASSERT(sizeof(PtrT) <= sizeof(AtomicWord),
 60                  PtrT_should_fit_in_AtomicWord);
 61
 62   PtrT Get() const {
 63     // Depending on the system, Acquire_Load(AtomicWord*) may have
 64     // been defined to return an AtomicWord, Atomic32, or Atomic64.
 65     // We hide that implementation detail here with an explicit cast.
 66     // This prevents MSVC 2005, at least, from complaining (it has to
 67     // do with __wp64; AtomicWord is __wp64, but Atomic32/64 aren't).
 68     return reinterpret_cast<PtrT>(static_cast<AtomicWord>(
 69       base::subtle::Acquire_Load(&data_)));
 70   }
 71
 72   // Sets the contained value to new_val and returns the old value,
 73   // atomically, with acquire and release semantics.
 74   // This is a full-barrier instruction.
 75   PtrT Exchange(PtrT new_val);
 76
 77   // Atomically executes:
 78   //      result = data_
 79   //      if (data_ == old_val)
 80   //        data_ = new_val;
 81   //      return result;
 82   // This is a full-barrier instruction.
 83   PtrT CompareAndSwap(PtrT old_val, PtrT new_val);
 84
 85   // Not private so that the class is an aggregate and can be
 86   // initialized by the linker. Don't access this directly.
 87   AtomicWord data_;
 88 };

Try changing 'AtomicWord data_;' to 'volatile AtomicWord data_;'. Let me know 
if this works for you and I will patch this on the development trunk.

Original comment by chapp...@gmail.com on 4 May 2012 at 4:17

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Seems It's not 'volatile' the compiler complains.
It is the type of AtomicWord that really matters. A simple test shows that, on 
AIX platform with gcc compiler, AtomicWord is different in 32-bit mode from 
64-bit mode.
AtomicWord is defined as intptr_t,which is:
in 32-bit mode(g++ without -maix64)
'long'
in 64-bit mode(g++ -max64)
'long long'
Atomic32 is always 'int', Atomic64 is 'long' in 32-bit mode and 'long long' in 
64-bit mode.

Based on that I made the following change:
let atomicops.h include  "base/atomicops-internals-linuxppc.h" rather than the 
default "base/atomicops-internals-x86.h"
change compile flags by modifing the generated Makefile
CPPFLAGS += -maix64
DEFS += -D__PPC64__ 

The previous error's gone yet the Assembling fails with some odd message like 
this:
Assembler:
/tmp//cczkcMl6.s: line 1793: 1252-142 Syntax error.
/tmp//cczkcMl6.s: line 1795: 1252-142 Syntax error.
...

Original comment by happysa...@gmail.com on 6 May 2012 at 4:27

[GoogleCodeExporter]

I am trying to build 32 bit library but getting many errors like
/tmp//ccMRhtoa.s: line 30107: 1252-142 Syntax error.
Do you have any solution to build TCMalloc with 32 bit on AIX 6.1

Original comment by mrityu....@gmail.com on 16 Nov 2012 at 10:22

[GoogleCodeExporter]

I think the problem is with atomicops-internals-XXX.h is not available for AIX

Original comment by mrityu....@gmail.com on 26 Nov 2012 at 1:32

[GoogleCodeExporter]

Original comment by chapp...@gmail.com on 23 Dec 2012 at 2:49

• Added labels: Type-Porting
• Removed labels: Type-Defect

[GoogleCodeExporter]

Issue 486 has been merged into this issue.

Original comment by alkondratenko on 14 Sep 2013 at 8:28