Failure to compile with the ppc cross compiler

[GoogleCodeExporter]

What steps will reproduce the problem?
1. ./configure
2.  make
3.

What is the expected output? What do you see instead?
 ccache powerpc-wrs-linux-gnu-e300c2-glibc_cgl-g++ -DHAVE_CONFIG_H -I. -I.
-I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -pthread -DNDEBUG
-Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare
-fno-exceptions -mpowerpc -mcpu=e300c2 -O2 -fno-rtti
-fno-implicit-templates -D__USE_STRING_INLINES -pipe -MT
libtcmalloc_minimal_internal_la-malloc_hook.lo -MD -MP -MF
.deps/libtcmalloc_minimal_internal_la-malloc_hook.Tpo -c src/malloc_hook.cc
 -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la-malloc_hook.o
src/malloc_hook.cc:451: error: declaration of C function `void*
mremap(void*, size_t, size_t, int, ...)' conflicts with
/home/sergeyt/Windriver/workspace/linux_pkgs_prj/host-cross/lib/../powerpc-wrs-l
inux-gnu/lib/include/sys/mman.h:123:
error: previous declaration `void* mremap(void*, size_t, size_t, int)' here
m

What version of the product are you using? On what operating system?
host machine: Linux 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686
i686 i386 GNU/Linux
crosscompiler:  powerpc-wrs-linux-gnu-e300c2-glibc_cgl-g++

How I understood the problem is in crosscompiler? 
How to solve this problem?

Original issue reported on code.google.com by yeg...@gmail.com on 9 May 2010 at 5:04

[GoogleCodeExporter]

Hmm, this is the same problem as issue 211.  There the problem was solved by 
using a
different compiler.  I guess that won't work here, because you need to use the
cross-compiler.

The interesting this is we have explicit code to handle this case, at the very 
top of
malloc_hook.cc:
---
// Disable the glibc prototype of mremap(), as older versions of the            
// system headers define this function with only four arguments,                
// whereas newer versions allow an optional fifth argument:                     
#ifdef HAVE_MMAP
# define mremap glibc_mremap
# include <sys/mman.h>
# undef mremap
#endif
---

I wonder if this code isn't triggering for you somehow.  Perhaps you don't have
HAVE_MMAP defined?  Can you attach to this bug report, your config.log file, 
and also
sys/config.h?

Original comment by csilv...@gmail.com on 9 May 2010 at 10:31

• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Thanks csilvers,

You are right, the HAVE_MMAP was not defined ... 
I have added this flag to configure and this error is over, 
but I got the new one:

/home/sergeyt/Windriver/gnu/3.4.4-wrlinux-1.5/x86-linux2/bin/../lib/gcc/powerpc-
wrs-linux-gnu/3.4.4/../../../../powerpc-wrs-linux-gnu/bin/ld:
tcmalloc::ThreadCache::threadlocal_heap_: TLS definition in
./.libs/libtcmalloc_minimal_internal.a(libtcmalloc_minimal_internal_la-thread_ca
che.o) section
.tbss mismatches non-TLS reference in .libs/libtcmalloc_minimal_la-tcmalloc.o
./.libs/libtcmalloc_minimal_internal.a(libtcmalloc_minimal_internal_la-thread_ca
che.o):
could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [libtcmalloc_minimal.la] Error 1

Seems more problematic, is it?
Attached config.log

Thanks,
yegres

Original comment by yeg...@gmail.com on 10 May 2010 at 12:15

Attachments:

• config.log

[GoogleCodeExporter]

OK,
Commenting of #define HAVE_TLS 1 
in config.h solves this problem.

Next one ;)
debugallocation_test-debugallocation_test.o: In function `global constructors 
keyed
to g_testlist':
debugallocation_test.cc:(.text+0xe10): undefined reference to `std::vector<void
(*)(), std::allocator<void (*)()> 
>::_M_insert_aux(__gnu_cxx::__normal_iterator<void
(**)(), std::vector<void (*)(), std::allocator<void (*)()> > >, void (* 
const&)())'
debugallocation_test.cc:(.text+0xe24): undefined reference to `std::vector<void
(*)(), std::allocator<void (*)()> 
>::_M_insert_aux(__gnu_cxx::__normal_iterator<void
(**)(), std::vector<void (*)(), std::allocator<void (*)()> > >, void (* 
const&)())'
debugallocation_test.cc:(.text+0xe38): undefined reference to `std::vector<void
(*)(), std::allocator<void (*)()> 
>::_M_insert_aux(__gnu_cxx::__normal_iterator<void
(**)(), std::vector<void (*)(), std::allocator<void (*)()> > >, void (* 
const&)())'
debugallocation_test.cc:(.text+0xe4c): undefined reference to `std::vector<void
(*)(), std::allocator<void (*)()> 
>::_M_insert_aux(__gnu_cxx::__normal_iterator<void
(**)(), std::vector<void (*)(), std::allocator<void (*)()> > >, void (* 
const&)())'
debugallocation_test.cc:(.text+0xe60): undefined reference to `std::vector<void
(*)(), std::allocator<void (*)()> 
>::_M_insert_aux(__gnu_cxx::__normal_iterator<void
(**)(), std::vector<void (*)(), std::allocator<void (*)()> > >, void (* 
const&)())'
debugallocation_test-debugallocation_test.o:debugallocation_test.cc:(.text+0xe74
):
more undefined references to `std::vector<void (*)(), std::allocator<void (*)()>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<void (**)(), std::vector<void 
(*)(),
std::allocator<void (*)()> > >, void (* const&)())' follow
./.libs/libtcmalloc_minimal_debug.so: undefined reference to
`base::internal::AtomicPtr<void (*)(void const*, unsigned int)>::Exchange(void
(*)(void const*, unsigned int))'
./.libs/libtcmalloc_minimal_debug.so: undefined reference to
`AddressMap<int>::Insert(void const*, int)'
./.libs/libtcmalloc_minimal_debug.so: undefined reference to
`AddressMap<int>::AddressMap(void* (*)(unsigned int), void (*)(void*))'
./.libs/libtcmalloc_minimal_debug.so: undefined reference to
`base::internal::AtomicPtr<void (*)(void const*, void const*, unsigned int, 
unsigned
int, int, void const*)>::Exchange(void (*)(void const*, void const*, unsigned 
int,
unsigned int, int, void const*))'
./.libs/libtcmalloc_minimal_debug.so: undefined reference to
`base::internal::AtomicPtr<void (*)(void const*, unsigned int, int, int, int,
long)>::Exchange(void (*)(void const*, unsigned int, int, int, int, long))'
./.libs/libtcmalloc_minimal_debug.so: undefined reference to
`base::internal::AtomicPtr<void (*)(void const*, void const*, unsigned int, 
int, int,
int, long)>::Exchange(void (*)(void const*, void const*, unsigned int, int, 
int, int,
long))'
./.libs/libtcmalloc_minimal_debug.so: undefined reference to `std::_Rb_tree<void
const*, std::pair<void const* const, char const*>, 
std::_Select1st<std::pair<void
const* const, char const*> >, std::less<void const*>, 
std::allocator<std::pair<void
const* const, char const*> > >::lower_bound(void const* const&)'
./.libs/libtcmalloc_minimal_debug.so: undefined reference to `std::_Rb_tree<void
const*, std::pair<void const* const, char const*>, 
std::_Select1st<std::pair<void
const* const, char const*> >, std::less<void const*>, 
std::allocator<std::pair<void
const* const, char const*> > 
>::insert_unique(std::_Rb_tree_iterator<std::pair<void
const* const, char const*> >, std::pair<void const* const, char const*> const&)'
./.libs/libtcmalloc_minimal_debug.so: undefined reference to
`base::internal::AtomicPtr<void (*)(int)>::Exchange(void (*)(int))'
./.libs/libtcmalloc_minimal_debug.so: undefined reference to
`base::internal::AtomicPtr<void (*)(void const*)>::Exchange(void (*)(void 
const*))'
./.libs/libtcmalloc_minimal_debug.so: undefined reference to
`base::internal::AtomicPtr<void (*)(void const*, int)>::Exchange(void (*)(void
const*, int))'
./.libs/libtcmalloc_minimal_debug.so: undefined reference to `std::_Rb_tree<void
const*, std::pair<void const* const, char const*>, 
std::_Select1st<std::pair<void
const* const, char const*> >, std::less<void const*>, 
std::allocator<std::pair<void
const* const, char const*> > >::_M_erase(std::_Rb_tree_node<std::pair<void 
const*
const, char const*> >*)'
collect2: ld returned 1 exit status
make[1]: *** [debugallocation_test] Error 1

Is there some dependence to STL or similar libraries?

Thanks,
yegres  

Original comment by yeg...@gmail.com on 10 May 2010 at 3:54

[GoogleCodeExporter]

OK, here is the line from config.log that shows why HAVE_MMAP isn't defined:
---
configure:20081: checking for working mmap
configure:20228: result: no
---
Not very informative, alas. :-(

You could try attaching your configure file as well, and maybe even the output 
of 'sh 
-x configure', but it looks to me like something is wrong with the 
cross-compile 
setup.  Your last comment makes me particularly suspicious: it can't find 
_Rb_tree::_M_erase.  This suggests that you're not linking against the proper 
libstdc++.so.  I feel like you're only 'half' cross-compiling somehow.

I also notice you're using ccache.  I wonder if that is throwing the build off 
at 
all.  Can you try turning that off?

Original comment by csilv...@gmail.com on 10 May 2010 at 11:17

[GoogleCodeExporter]

Any more news on this?

Original comment by csilv...@gmail.com on 7 Jun 2010 at 11:12

[GoogleCodeExporter]

Hi csilvers,

At this time I have put the integration of google-perftools in the side. 
Because how I undersood, there is a problem with my cross compiler, is more 
exact with the old libraries. 
I have the older version of libstdc++.so, therefore linker complains on 
undefined reference. Now I plan to upgrade my toolchain with the last WR 
version. Hope it will help me to integrate the google-perftools in the future.

Thanks,
yegres. 

Original comment by yeg...@gmail.com on 8 Jun 2010 at 12:18

[GoogleCodeExporter]

OK, I'll close this for now.  Feel free to reopen if you find there's a problem 
with perftools itself.

Original comment by csilv...@gmail.com on 8 Jun 2010 at 7:08

• Changed state: CannotReproduce