DavidMorre / gperftools

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

Unable to build using mipsel-linux-gcc based on uclibc #242

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. ./configure --host=mipsel-linux
2. make
3.

What is the expected output? What do you see instead?
if /bin/sh ./libtool --tag=CXX --mode=compile mipsel-linux-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 -MT libtcmalloc_minimal_la-tcmalloc.lo -MD -MP -MF 
".deps/libtcmalloc_minimal_la-tcmalloc.Tpo" -c -o libtcmalloc_minimal_la-
tcmalloc.lo `test -f 'src/tcmalloc.cc' || echo './'`src/tcmalloc.cc; \
        then mv -f ".deps/libtcmalloc_minimal_la-tcmalloc.Tpo" 
".deps/libtcmalloc_minimal_la-tcmalloc.Plo"; else rm -f 
".deps/libtcmalloc_minimal_la-tcmalloc.Tpo"; exit 1; fi
mkdir .libs
 mipsel-linux-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 -MT libtcmalloc_minimal_la-tcmalloc.lo -MD 
-MP -MF .deps/libtcmalloc_minimal_la-tcmalloc.Tpo -c src/tcmalloc.cc  -fPIC 
-DPIC -o .libs/libtcmalloc_minimal_la-tcmalloc.o
src/tcmalloc.cc:279: error: declaration of C function 'void malloc_stats()' 
conflicts with
/tools/mips/crosstools_hf-linux-2.6.18.0_gcc-4.2-11ts_uclibc-nptl-0.9.29-
20070423_20090508/bin/../lib/gcc/mipsel-linux-
uclibc/4.2.0/../../../../mipsel-linux-uclibc/sys-include/malloc.h:157: 
error: previous declaration 'void malloc_stats(FILE*)' here
gmake: *** [libtcmalloc_minimal_la-tcmalloc.lo] Error 1

What version of the product are you using? On what operating system?
toolschain: crosstools_hf-linux-2.6.18.0_gcc-4.2-11ts_uclibc-nptl-0.9.29-
20070423_20090508/

Please provide any additional information below.
How I understood the problem is in crosscompiler and different API for 
malloc_stats? 

Original issue reported on code.google.com by mile.dav...@gmail.com on 20 May 2010 at 4:56

GoogleCodeExporter commented 9 years ago
This looks to be a problem not in the cross-compiling, per se, but in the fact 
you're 
using uclibc.  It looks like uclibc has a different function signature for 
malloc_stats than glibc does.  I don't think malloc_stats is a standard posix 
function, so I guess this is reasonable, in a way.

I guess I can add a configure check that will handle this case.  It will be a 
little 
hard for me to test, unfortunately, since I don't have a uclibc system 
anywhere.  I'll 
try to make it available for the next release.

Original comment by csilv...@gmail.com on 20 May 2010 at 5:58

GoogleCodeExporter commented 9 years ago
btw, as a temporary workaround for you personally, every place you see 
tc_malloc_stats(void) in tcmalloc.cc, just change it to tc_malloc_stats(FILE* 
fp).  
You may need to fix up a few call sites as well, but it should be pretty 
straightforward.

Original comment by csilv...@gmail.com on 20 May 2010 at 6:00

GoogleCodeExporter commented 9 years ago
I already started changing tc_malloc_stats but I did not finished yet due some 
other 
obligations.  

I will try to help You as much as possible with testing when You prepare 
official patch 
...

Original comment by mile.dav...@gmail.com on 21 May 2010 at 7:18

GoogleCodeExporter commented 9 years ago
I have an arm system where I am using ulibc also and am running into the same 
problem.   I attempted changing tc_malloc_stats(void) to tc_malloc_stats(FILE* 
fp), but it did not really help as there are other compile issues, and I am not 
sure if they are caused by my changes or more problems with ulibc.  Has anyone 
else gotten perftools to work with ulibc?

Original comment by darre...@gmail.com on 16 Aug 2011 at 9:19

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, OSes, 
and compilers, but otherwise we are limited to the ones mentioned in the 
INSTALL file.  (Though, to be fair, I don't know how much we talk about 
compilers.)

Original comment by csilv...@gmail.com on 31 Aug 2011 at 11:38