Failure to build (1.4 || 1.5) on amd64 RHEL5.

[GoogleCodeExporter]

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

RHEL5.2 2.6.18-128.el5 amd64

What is the expected output? What do you see instead?

Expect compilation to be successful, instead get;

 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 -DNO_FRAME_POINTER -fno-exceptions -g -O2 -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/base/linux_syscall_support.h: In function ‘int sys_recvmsg(int, 
kernel_msghdr*, int)’:
src/base/linux_syscall_support.h:2376: error: ‘__NR_recvmsg’ was not 
declared in this scope
src/base/linux_syscall_support.h: In function ‘int sys_sendmsg(int, const 
kernel_msghdr*, int)’:
src/base/linux_syscall_support.h:2378: error: ‘__NR_sendmsg’ was not 
declared in this scope
src/base/linux_syscall_support.h: In function ‘int sys_sendto(int, const 
void*, size_t, int, const kernel_sockaddr*, int)’:
src/base/linux_syscall_support.h:2380: error: ‘__NR_sendto’ was not 
declared in this scope
src/base/linux_syscall_support.h: In function ‘int sys_shutdown(int, int)’:
src/base/linux_syscall_support.h:2384: error: ‘__NR_shutdown’ was not 
declared in this scope
src/base/linux_syscall_support.h: In function ‘int sys_socket(int, int, 
int)’:
src/base/linux_syscall_support.h:2386: error: ‘__NR_socket’ was not 
declared in this scope
src/base/linux_syscall_support.h: In function ‘int sys_socketpair(int, int, 
int, int*)’:
src/base/linux_syscall_support.h:2388: error: ‘__NR_socketpair’ was not 
declared in this scope
make: *** [libtcmalloc_minimal_internal_la-malloc_hook.lo] Error 1
Please provide any additional information below.

What version of the product are you using? On what operating system?

1.4 (included with ruby enterprise 1.8.7) or 1.5 (downloaded from google code)

Original issue reported on code.google.com by ether...@gmail.com on 10 Jun 2010 at 5:49

Attachments:

• config.log

[GoogleCodeExporter]

I notice these are defined in unistd.h;

[root@20020lpweb09 google-perftools-1.4]# locate unistd.h
/usr/include/unistd.h
/usr/include/asm/unistd.h
/usr/include/asm-i386/unistd.h
/usr/include/asm-x86_64/unistd.h
/usr/include/bits/unistd.h
/usr/include/linux/unistd.h
/usr/include/sys/unistd.h

The x86_64 one of these is owned by kernel-headers-2.6.18-164.10.1.el5

Original comment by ether...@gmail.com on 10 Jun 2010 at 5:51

[GoogleCodeExporter]

Strike all refs to amd64, it's actually x86_64, my apologies.

Original comment by ether...@gmail.com on 10 Jun 2010 at 6:06

[GoogleCodeExporter]

linux_syscall_support.h #includes linux/unistd.h.  What is the contents of that 
file for you?

On my x86_64 machine, it #includes asm/unistd.h, which #includes 
asm/unistd_64.h.  That file defines these __NR_* constants.

I'm guessing your situations is something different.  Can you report what it 
is?  Maybe attach the final .h file that actually has the #included content.

Original comment by csilv...@gmail.com on 10 Jun 2010 at 4:52

• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

I ended up just copying a binary release of REE + perftools from a twin machine 
with the exact same OS release and this worked fine.

However, would still be good to know what this problem was, so;

/usr/include/linux/unistd.h
/usr/include/asm-x86_64/unistd.h

tarred up and attached.

Original comment by ether...@gmail.com on 10 Jun 2010 at 11:43

Attachments:

• unistd.tar.gz

[GoogleCodeExporter]

To clarify, a binary release that I had actually compiled from source on that 
aforementioned twin machine, so it may be some weird juju specifically related 
to this particular server causing that compile time error.

Original comment by ether...@gmail.com on 10 Jun 2010 at 11:44

[GoogleCodeExporter]

Weird, the asm/unistd.h looks fine to me.  It definitely defines these 
constants.

Next step, if you wanted to look into it further, would be to run through the 
preprocessor and try to figure out what is being #included, and why it's not 
getting these constants:

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 -DNO_FRAME_POINTER -fno-exceptions -g -O2 -MT 
libtcmalloc_minimal_internal_la-malloc_hook.lo -MD -MP -MF 
.deps/libtcmalloc_minimal_internal_la-malloc_hook.Tpo -E src/malloc_hook.cc  
-fPIC -DPIC | less

In any case, it looks like it's not a bug in tcmalloc anywhere, so I'm closing 
this as Invalid.

Original comment by csilv...@gmail.com on 11 Jun 2010 at 3:10

• Changed state: Invalid