search

blueszhangsh / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

ERROR - Installing the perftool with gcc 2.95 #135

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I just downloaded the perftool and tried make check. I got the following error.

$ make check
source='src/tcmalloc.cc' object='libtcmalloc_minimal_la-tcmalloc.lo'
libtool=yes \
DEPDIR=.deps depmode=gcc /bin/sh ./depcomp \
/bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.
-I./src  -I./src   -DNO_TCMALLOC_SAMPLES -pthread -DNDEBUG -Wall
-Wwrite-strings -Woverloaded-virtual -Wno-sign-compare   -g -O2 -c -o
libtcmalloc_minimal_la-tcmalloc.lo `test -f 'src/tcmalloc.cc' || echo
'./'`src/tcmalloc.cc
 g++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src -DNO_TCMALLOC_SAMPLES -pthread
-DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -g
-O2 -c src/tcmalloc.cc -Wp,-MD,.deps/libtcmalloc_minimal_la-tcmalloc.TPlo 
-fPIC -DPIC -o .libs/libtcmalloc_minimal_la-tcmalloc.o
In file included from src/tcmalloc.cc:116:
src/base/spinlock.h:70: macro `EXCLUSIVE_LOCK_FUNCTION' used without args
src/base/spinlock.h:90: macro `UNLOCK_FUNCTION' used without args
src/base/spinlock.h:147: macro `UNLOCK_FUNCTION' used without args
make: *** [libtcmalloc_minimal_la-tcmalloc.lo] Error 1

Original issue reported on code.google.com by moha...@gmail.com on 27 May 2009 at 6:18

GoogleCodeExporter commented 9 years ago 
Interesting -- what OS and compiler are you using?  I wouldn't expect to see 
this
problem with gcc, which it appears that you're using.  What version of g++?  
Did you
pass any special flags to configure?

In any case, the workaround is simple enough: just comment out these macros in
spinlock.h; they're not doing anything yet.  eg, on line 70:
   inline void Lock() /*EXCLUSIVE_LOCK_FUNCTION()*/ {

The latest version in the SVN repository should already have this fix.  It will 
be
part of the next release.

Original comment by csilv...@gmail.com on 27 May 2009 at 6:28

GoogleCodeExporter commented 9 years ago 
Thanks for the reply. Please find the system details below.

Linux OS
compiler - gcc
g++ version - 2.95.3

I commented the code as you suggested, but then i end up with some other error 
given
below.
$ make check
source='src/tcmalloc.cc' object='libtcmalloc_minimal_la-tcmalloc.lo' 
libtool=yes \
DEPDIR=.deps depmode=gcc /bin/sh ./depcomp \
/bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I./src 
-I./src   -DNO_TCMALLOC_SAMPLES -pthread -DNDEBUG -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare   -g -O2 -c -o
libtcmalloc_minimal_la-tcmalloc.lo `test -f 'src/tcmalloc.cc' || echo
'./'`src/tcmalloc.cc
 g++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src -DNO_TCMALLOC_SAMPLES -pthread -DNDEBUG
-Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -g -O2 -c
src/tcmalloc.cc -Wp,-MD,.deps/libtcmalloc_minimal_la-tcmalloc.TPlo  -fPIC -DPIC 
-o
.libs/libtcmalloc_minimal_la-tcmalloc.o
In file included from src/base/atomicops.h:97,
                 from src/base/spinlock.h:48,
                 from src/tcmalloc.cc:116:
src/base/atomicops-internals-x86.h: In function `void
base::subtle::NoBarrier_Store(volatile Atomic64 *, long long int)':
src/base/atomicops-internals-x86.h:364: unknown register name `%mm0' in `asm'
src/base/atomicops-internals-x86.h: In function `Atomic64
base::subtle::NoBarrier_Load(const volatile Atomic64 *)':
src/base/atomicops-internals-x86.h:384: unknown register name `%mm0' in `asm'
src/tcmalloc.cc: In function `void DumpStats(TCMalloc_Printer *, int)':
src/tcmalloc.cc:260: warning: unknown conversion type character `z' in format
src/tcmalloc.cc:260: warning: long long unsigned int format, different type arg 
(arg 4)
src/tcmalloc.cc:260: warning: double format, different type arg (arg 5)
src/tcmalloc.cc:260: warning: too many arguments for format
src/tcmalloc.cc: At top level:
src/tcmalloc.cc:1143: use of `mallinfo' is ambiguous
/usr/include/malloc.h:171:   first declared as `struct mallinfo mallinfo()' here
/usr/include/malloc.h:168:   also declared as `struct mallinfo' here
make: *** [libtcmalloc_minimal_la-tcmalloc.lo] Error 1

Original comment by moha...@gmail.com on 27 May 2009 at 10:57

GoogleCodeExporter commented 9 years ago 
Wow, gcc 2.95.  It looks like, in practice, perftools needs gcc 3 or higher to
compile.  It's probably not too hard to make the changes to get things to work 
under
gcc 2, but I don't know enough about gcc 2 to be able to try to do it.  If you 
can
figure it out, I'd be glad to accept patches!

It looks like the asm syntax has changed a bit from gcc 2 to gcc 3, so you'll 
have to
fix that.

The 'unknown conversion type character `z' in format' concerns me: our configure
checks are supposed to correctly detect that and do the right thing.  You'd 
have to
look through the config.log for that one.  My guess is that 'z' is the default 
the
configure script uses when it can't figure out anything better, and that's what
happened here.  But I would have expected 'll' to work, and the configure script
should have found it.

'use of 'mallinfo' is ambiguous' is just bizarre.  How are you supposed to 
refer to
the function, if it's always going to think it's ambiguous with the type-name? 
Assuming you don't use mallinfo -- and few people do -- a workaround might be 
to just
take all mallinfo references out of tcmalloc.cc.  That still keeps the asm 
error in
there though, and there's no getting around that one.

Original comment by csilv...@gmail.com on 27 May 2009 at 6:54

GoogleCodeExporter commented 9 years ago

Original comment by csilv...@gmail.com on 27 May 2009 at 6:54

GoogleCodeExporter commented 9 years ago 
At least some of this should be fixed in perftools 1.6, just released.

Original comment by csilv...@gmail.com on 5 Aug 2010 at 8:45

GoogleCodeExporter commented 9 years ago 
I've decided to close all the porting requests that don't have patches attached 
to them.  We're always happy to look at patches for new architectures and OSes, 
but otherwise we are limited to the CPUs and OSes mentioned in the INSTALL file.

I doubt we'll ever support gcc 2.95 though.  gcc 3 is now over 10 years old.

Original comment by csilv...@gmail.com on 31 Aug 2011 at 1:16