Compiling fails on snow leopard
GoogleCodeExporter opened this issue · comments
What steps will reproduce the problem?
1. Compiling on Snow Leopard
What is the expected output? What do you see instead?
A working version
What version of the product are you using? On what operating system?
Snow Leopard, Perftools 1.4
Please provide any additional information below.
Compiling fails with the following error:
creating libtcmalloc_debug.la
(cd .libs && rm -f libtcmalloc_debug.la && ln -s ../libtcmalloc_debug.la
libtcmalloc_debug.la)
if /bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.
-I./src -I./src -Wall -Wwrite-strings -Woverloaded-virtual
-Wno-sign-compare -DNO_FRAME_POINTER -g -O2 -MT profiler.lo -MD -MP -MF
".deps/profiler.Tpo" -c -o profiler.lo `test -f 'src/profiler.cc' || echo
'./'`src/profiler.cc; \
then mv -f ".deps/profiler.Tpo" ".deps/profiler.Plo"; else rm -f
".deps/profiler.Tpo"; exit 1; fi
g++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare -DNO_FRAME_POINTER -g -O2 -MT
profiler.lo -MD -MP -MF .deps/profiler.Tpo -c src/profiler.cc -fno-common
-DPIC -o .libs/profiler.o
In file included from src/profiler.cc:37:
src/getpc.h:178: error: expected ‘,’ or ‘...’ before ‘&’ token
src/getpc.h:178: error: ISO C++ forbids declaration of ‘ucontext_t’ with no
type
src/getpc.h: In function ‘void* GetPC(int)’:
src/getpc.h:179: error: ‘signal_ucontext’ was not declared in this scope
src/profiler.cc: At global scope:
src/profiler.cc:49: error: conflicting declaration ‘typedef int ucontext_t’
/usr/include/sys/_structs.h:227: error: ‘ucontext_t’ has a previous
declaration as ‘typedef struct __darwin_ucontext ucontext_t’
In file included from src/base/commandlineflags.h:55,
from src/profiler.cc:55:
./src/base/basictypes.h: In constructor
‘AssignAttributeStartEnd::AssignAttributeStartEnd(const char*, char**,
char**)’:
./src/base/basictypes.h:251: warning: ‘_dyld_present’ is deprecated
(declared at /usr/include/mach-o/dyld.h:237)
./src/base/basictypes.h:251: warning: ‘_dyld_present’ is deprecated
(declared at /usr/include/mach-o/dyld.h:237)
src/profiler.cc: In static member function ‘static void
CpuProfiler::prof_handler(int, siginfo_t*, void*, void*)’:
src/profiler.cc:266: error: cannot convert ‘__darwin_ucontext’ to ‘int’
for
argument ‘1’ to ‘void* GetPC(int)’
make: *** [profiler.lo] Error 1
Original issue reported on code.google.com by sebastia...@gmail.com on 16 Sep 2009 at 9:07
Hmm, unfortunately I don't have access to a snow leopard machine for testing.
It
looks like /usr/include/ucontext.h doesn't exist on that version of the OS?
And that
the existing places we look for the ucontext-register (at configure time) don't
work
either?
This is pretty easy to figure out if I had access to a machine, but may be
harder
without it. :-( Can you attach your 'config.log' file to this bug report? And
also
your src/config.h file? I'll see if that helps figure things out.
Original comment by csilv...@gmail.com on 16 Sep 2009 at 4:21
/usr/include/ucontext.h exists (as attached)
Original comment by sebastia...@gmail.com on 16 Sep 2009 at 7:34
Attachments:
ucontext.h does indeed exist, but it has this code:
---
#error ucontext routines are deprecated, and require _XOPEN_SOURCE to be defined
---
The #error causes compiles to fail, which is what was happening here. Poking
around
the web, it looks like the solution is to #include <sys/uncontext.h> instead.
Here's a patch that may fix the problem for you. Give it a try and let me know.
Original comment by csilv...@gmail.com on 16 Sep 2009 at 7:43
- Added labels: Priority-Medium, Type-Defect
Attachments:
Defining _XOPEN_SOURCE allows it to build, but then there is a segfault when the
process is exiting. I have dug through the code to try to find exactly where
this is
happening but I can't pin it down, so I don't know if I am overlooking
something or
if gdb is giving me screwed up info. Backtrace is attached.
Original comment by jakecdou...@gmail.com on 17 Sep 2009 at 4:04
Attachments:
OK, _XOPEN_SOURCE also gets around the #error in ucontext.h, so that makes it
seem
like that's the only problem there. I'll change the code to prefer
sys/ucontext.h in
the next release.
As for the segfault -- it's really a EXC_BAD_ACCESS fault -- it's a bit hard to
tell
what's going on from the gdb stacktrace. Can you try rebuilding perftools with
optimization turned off, and trying again? You'll need to do something like
./configure CXXFLAGS=-g
My guess is that dyld_get_image_header or some other routines used in
GetNextExt have
changed in the new OS release, but I don't know for sure. More exact debug info
should help narrow it down.
Original comment by csilv...@gmail.com on 17 Sep 2009 at 5:43
Doesn't seem to yield a whole lot more. Let me know what else I can do to help
you
narrow it down. I'll keep poking around.
Original comment by jakecdou...@gmail.com on 17 Sep 2009 at 8:39
Attachments:
} Reason: 13 at address: 0x0000000000000000
Ah, so it *is* a segfault: a null-pointer dereference.
I see the stacktrace has line numbers for everything except the procmapsiterator
code. Is it possible you compiled base/sysinfo.cc without debug information?
A line
number here would definitely help. (Also, if you get it, let me know what that
line
looks like, just to make sure our line numbers are synchronized.)
Original comment by csilv...@gmail.com on 17 Sep 2009 at 8:45
base/sysinfo.cc is getting built with the correct flags, so I am not sure why
it does
not report a line number.
Original comment by jakecdou...@gmail.com on 17 Sep 2009 at 9:10
It is trying to load the object file from a bad location:
warning: Could not find object file
"/Users/jake/development/google-perftools-1.4/.libs/libprofiler.lax/libstacktrac
e.a/sysinfo.o"
- no debug information available for "src/base/sysinfo.cc".
how can I fix this?
Original comment by jakecdou...@gmail.com on 17 Sep 2009 at 10:05
I'm afraid I don't know enough about building on OS X (or maybe it's just
libtool) to
say. Does the file .libs/libprofiler.lax/libstacktrace.a/sysinfo.o exist?
Original comment by csilv...@gmail.com on 17 Sep 2009 at 10:25
Line 734 in sysinfo.cc is where it is failing:
lc += ((const load_command *)lc)->cmdsize;
Original comment by jakecdou...@gmail.com on 17 Sep 2009 at 10:34
Ah, interesting. That doesn't make much sense though: the error would suggest
lc is
0, but that seems to be impossible:
---
const char* lc = ((const char *)hdr + sizeof(struct mach_header));
for (int j = 0; j < current_load_cmd_; j++) // advance to *our* load_cmd
lc += ((const load_command *)lc)->cmdsize;
---
It's possible, but seems bizarre, that lc could ever wrap around to 0.
Is it possible for you to put a breakpoint here in gdb, and then see what lc
looks
like as you iterate through the code?
Original comment by csilv...@gmail.com on 17 Sep 2009 at 10:38
The issue was that it did not support 64 bit mach-o files. I have attached an
svn
diff from trunk (which seems to be the 1.4 release) that works for me. I was
not sure
if there was a good way to clean it up more. The change just checks the mach
header
to see if it is 64 bit, then if so, substitutes appropriate mach_header_64,
LC_SEGMENT_64, and segment_command_64. Please let me know. thanks
Original comment by jakecdou...@gmail.com on 19 Sep 2009 at 10:05
Attachments:
Thanks for tracking this down, and submitting a patch! I'll have this fixed up
for
the next release.
Original comment by csilv...@gmail.com on 21 Sep 2009 at 1:38
- Changed state: Started
The folks who help me with this file are worried about all the typedefs, so I
rewrote
it in a way to minimize typedefs. It now uses templates to avoid code
duplication.
I'm not sure this approach is easier to read or harder; see what you think.
I can't even really compile it, since I don't have a 64-bit mach-o system to
test on.
Do you mind trying this patch and seeing how it works for you? Let me know what
needs to be fixed up.
Original comment by csilv...@gmail.com on 22 Sep 2009 at 11:08
Attachments:
The patch does not apply for me. I tried to jimmy it in but didn't get it
working.
NextExtMachHelper would need to be a member function so it has access to
current_load_cmd_. I don't know anything about templates so I don't really know
how
it should or should not look or work. I assume by worried about the 'typedefs'
you
mean casting? The way presented here is just about as much code as duplicating
it. I
think the way I had it originally is more clear, but I'm not a C++ guy and not
the
person who will be maintaining the code in the future, so it's up to you. If
you can
show me how to apply the patches correctly I am happy to test them for you.
Original comment by jakecdou...@gmail.com on 22 Sep 2009 at 11:59
Oddly, I don't have any problems until I get to 'make check' with current
xcode, as
per other issue I opened.
Original comment by bimargul...@gmail.com on 30 Sep 2009 at 12:51
Sorry, my mistake -- I meant 'worried about the #ifdefs', not worried about the
typedefs. We're trying to keep the #ifdefs to a minimum, because they really
make
the code hard to read. When we do have ifdefs we try to make them enclose
logical
blocks, like entire functions. My patch is basically your patch, but rewritten
to
have the #ifdefs have that property.
I've attached a new version of the patch, that passes in current_image_ et al.
so the
code will hopefully come closer to compiling now. Let me know how it works.
Original comment by csilv...@gmail.com on 2 Oct 2009 at 7:13
Attachments:
Issue 175 has been merged into this issue.
Original comment by csilv...@gmail.com on 2 Oct 2009 at 7:15
The patch is missing a prototype for NextExtMachHelper in sysinfo.h. After
adding
one, I get this error, which I don't really understand:
src/base/sysinfo.cc: In member function ‘bool
ProcMapsIterator::NextExt(uint64*,
uint64*, char**, uint64*, int64*, char**, uint64*, uint64*, uint64*, uint64*,
dev_t*)’:
src/base/sysinfo.cc:771: error: ISO C++ forbids comparison between pointer and
integer
src/base/sysinfo.cc:771: warning: left-hand operand of comma has no effect
src/base/sysinfo.cc:772: error: expected primary-expression before ‘struct’
src/base/sysinfo.cc:772: error: expected `)' before ‘struct’
src/base/sysinfo.cc:780: error: ISO C++ forbids comparison between pointer and
integer
src/base/sysinfo.cc:780: warning: left-hand operand of comma has no effect
src/base/sysinfo.cc:781: error: expected primary-expression before ‘struct’
src/base/sysinfo.cc:781: error: expected `)' before ‘struct’
src/base/sysinfo.cc:757: warning: unused variable ‘kDefaultPerms’
make: *** [sysinfo.lo] Error 1
Original comment by jakecdou...@gmail.com on 11 Oct 2009 at 4:17
Why do you need NextExtMachHelper in sysinfo.h? It should only be used
internally
within the sysinfo.cc file. What error were you getting?
Oh, I think part of the problem is that I did
#ifdef OS_MACOSX
which is a typo. It should be something like #ifdef __MACH__. Does that make
things
any better?
Original comment by csilv...@gmail.com on 13 Oct 2009 at 9:31
http://predef.sourceforge.net/preos.html#sec19
__APPLE__ & __MACH__
Original comment by anuj.go...@gmail.com on 14 Oct 2009 at 4:03
Whoops, my mistake. Changing it to check for __MACH__ fixes that part. The only
other
thing then is that the initialization of kDefaultPerms needs to be moved into
that
area, then it works fine.
Thanks
Original comment by jakecdou...@gmail.com on 16 Oct 2009 at 8:17
This is the error that I'm getting on Snow Leopard after applying csilvers's
patch
and changing OS_MACOSX to __MACH__:
g++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare -DNO_FRAME_POINTER -g -O2 -c
src/base/sysinfo.cc -fno-common -DPIC -o .libs/sysinfo.o
In file included from ./src/base/sysinfo.h:48,
from src/base/sysinfo.cc:57:
./src/base/basictypes.h: In constructor
'AssignAttributeStartEnd::AssignAttributeStartEnd(const char*, char**, char**)':
./src/base/basictypes.h:251: warning: '_dyld_present' is deprecated (declared at
/usr/include/mach-o/dyld.h:237)
./src/base/basictypes.h:251: warning: '_dyld_present' is deprecated (declared at
/usr/include/mach-o/dyld.h:237)
src/base/sysinfo.cc: In function 'bool NextExtMachHelper(const mach_header*,
int,
int, uint64*, uint64*, char**, uint64*, int64*, char**, uint64*, uint64*,
uint64*,
uint64*, dev_t*)':
src/base/sysinfo.cc:468: error: 'kDefaultPerms' was not declared in this scope
src/base/sysinfo.cc: In member function 'bool ProcMapsIterator::NextExt(uint64*,
uint64*, char**, uint64*, int64*, char**, uint64*, uint64*, uint64*, uint64*,
dev_t*)':
src/base/sysinfo.cc:757: warning: unused variable 'kDefaultPerms'
make: *** [sysinfo.lo] Error 1
Strangely, replacing 'kDefaultPerms' with "r-xp" made it bail out with the
original
error:
g++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare -DNO_FRAME_POINTER -g -O2 -c
src/profiler.cc
-fno-common -DPIC -o .libs/profiler.o
In file included from src/profiler.cc:37:
src/getpc.h:178: error: expected ',' or '...' before '&' token
src/getpc.h:178: error: ISO C++ forbids declaration of 'ucontext_t' with no type
src/getpc.h: In function 'void* GetPC(int)':
src/getpc.h:179: error: 'signal_ucontext' was not declared in this scope
src/profiler.cc: At global scope:
src/profiler.cc:49: error: conflicting declaration 'typedef int ucontext_t'
/usr/include/sys/_structs.h:227: error: 'ucontext_t' has a previous declaration
as
'typedef struct __darwin_ucontext ucontext_t'
In file included from src/base/commandlineflags.h:55,
from src/profiler.cc:55:
./src/base/basictypes.h: In constructor
'AssignAttributeStartEnd::AssignAttributeStartEnd(const char*, char**, char**)':
./src/base/basictypes.h:251: warning: '_dyld_present' is deprecated (declared at
/usr/include/mach-o/dyld.h:237)
./src/base/basictypes.h:251: warning: '_dyld_present' is deprecated (declared at
/usr/include/mach-o/dyld.h:237)
src/profiler.cc: In static member function 'static void
CpuProfiler::prof_handler(int, siginfo_t*, void*, void*)':
src/profiler.cc:266: error: cannot convert '__darwin_ucontext' to 'int' for
argument
'1' to 'void* GetPC(int)'
Original comment by honglilai@gmail.com on 26 Oct 2009 at 8:41
Heh, funny. :-) It is possible somewhere it got changed back to #include
<ucontext.h> instead of #include <sys/ucontext.h>?
Original comment by csilv...@gmail.com on 26 Oct 2009 at 9:12
I had been building with -D_XOPEN_SOURCE, so that is why I didn't encounter that
issue. Would you like me to put together a full patch that applies to 1.4? I am
a
little out of touch as far as what you have merged already.
Original comment by jakecdou...@gmail.com on 26 Oct 2009 at 9:19
I think I'm all set with having merged everything in, thanks!
Original comment by csilv...@gmail.com on 26 Oct 2009 at 9:39
I'm seeing this same problem. Is there a single patch I can apply to fix this
issue?
Original comment by sjha...@gmail.com on 14 Dec 2009 at 10:57
I'm not sure if there's a single patch you can apply, but the version of
perftools
from svn-root has the fix. You could try that. If you'd prefer not, you can
try
patching in r77 from SVN:
http://code.google.com/p/google-perftools/source/detail?r=77
You may want some of the r78 diffs too, in particular the ones to sysinfo.{h,cc}
Original comment by csilv...@google.com on 15 Dec 2009 at 12:22
This should be fixed in perftools 1.5, just released.
Original comment by csilv...@gmail.com on 20 Jan 2010 at 11:04
Original comment by csilv...@gmail.com on 20 Jan 2010 at 11:05
- Changed state: Fixed
What version of the product are you using? On what operating system?
I was building PerfTools 1.7 on Linux : SUSE LINUX Enterprise Server 9 Kernel
2.6.5-7.97.
Configure run with : --disable-cpu-profiler
Compile fails with :
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src -Wall
-Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc
-fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree
-fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc
-fno-builtin-pvalloc -g -O2 -MT stacktrace.lo -MD -MP -MF .deps/stacktrace.Tpo
-c src/stacktrace.cc -fPIC -DPIC -o .libs/stacktrace.o
In file included from src/stacktrace.cc:65:
src/stacktrace_x86-inl.h: In function `void** NextStackFrame(void**, const
void*)':
src/stacktrace_x86-inl.h:188: error: ISO C++ forbids declaration of `ucontext_t
' with no type
src/stacktrace_x86-inl.h:188: error: syntax error before `*' token
and goes on...
Original comment by kiniaks...@gmail.com on 18 Feb 2011 at 8:20
Can you please open a new bug report for this? This bug has to do with
compiling on snow leopard, not SUSE.
Original comment by csilv...@gmail.com on 18 Feb 2011 at 9:24