Closed GoogleCodeExporter closed 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
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
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
Original comment by csilv...@gmail.com
on 27 May 2009 at 6:54
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
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
Original issue reported on code.google.com by
moha...@gmail.com
on 27 May 2009 at 6:18