I am attempting to build Google Breakpad for Mac OS X as a part of porting an application, based on the trunk revision 782.
The Breakpad wiki specifies that one should build client/mac/Breakpad.xcodeproj, which produces a Breakpad.framework including a dynamically linked lib if I understand correctly. There is also sample code on how to use this from an Objective-C application, but all this seem very different from what seems to be the normal way of doing things on other platforms, including the use of plists and other things that are not part of my application. I would much rather do things as similar as possible across platforms.
For instance, this appears to be the way that Firefox uses Breakpad:
// include exception_handler.h from client/<platform>/handler,
// using ... here for brevity
#include "... exception_handler.h"
...
gExceptionHandler = new google_breakpad::
ExceptionHandler(tempPath.get(),
nsnull,
MinidumpCallback,
nsnull,
#if defined(XP_WIN32)
google_breakpad::ExceptionHandler::HANDLER_ALL);
#else
true);
#endif
In my project, we are doing the same thing and just link against exception_handler.lib
on Windows. It seems that on Linux, Breakpad generates a corresponding libbreakpad_client.a
that can be linked against in the same way, but not on Mac OS X. If I do
./configure
make
from the breakpad root directory a libbreakpad.a
is generated that does not contain the exception handler, and the libbreakpad_client.a that should is not being built. I may very well have misunderstood just about anything on both the normal way of using Breakpad as well as the normal procedure for building external libraries on the Mac, so any help is appreciated.
How do I build libbreakpad_client.a
on Mac OS X?
There is no solution in the Breakpad source for this, unfortunately. The XCode projects simply build the Breakpad framework, as that's the more-supported client API. You can build the code with your own set of Makefiles or whatever build setup you desire the same way Firefox does by looking at the set of Mozilla makefiles:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/common/Makefile.in
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/common/mac/Makefile.in
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/client/Makefile.in
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/client/mac/handler/Makefile.in
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/client/mac/crash_generation/Makefile.in
and gathering the set of files referenced in CSRCS/CPPSRCS/CMSRCS/CMMSRCS, and building all of those.
You might also file a bug in the Breakpad issue tracker to ask that the XCode project build this static library as well. It would not be a difficult patch.
This might not be helpful in your case, but I've found this to work for a project I'm working on that needs to work on both Linux and OSX. On Linux we use the "normal" autotools way of doing things; on OSX we invoke xcodebuild to create Breakpad.framework
and then link against that.
Here's the relevant portion of the CMakeLists.txt file (for CMake see here):
IF(LINUX)
add_custom_target(
GOOGLE_BREAKPAD_MAKEFILE
COMMAND cd ../google-breakpad/ && ([ -e Makefile ] || (autoreconf && bash configure))
)
add_custom_target(
GOOGLE_BREAKPAD
COMMAND cd ../google-breakpad/ && $(MAKE)
)
add_dependencies(GOOGLE_BREAKPAD GOOGLE_BREAKPAD_MAKEFILE)
ENDIF()
IF(APPLE)
add_custom_target(
GOOGLE_BREAKPAD
COMMAND cd ../google-breakpad/src/client/mac/ && xcodebuild -sdk macosx
)
ENDIF()
If your application is built with clang -stdlib=libc++
(which is pretty normal if you make heavy use of C++11), you should append the phrase GCC_VERSION=com.apple.compilers.llvm.clang.1_0 OTHER_CFLAGS=-stdlib=libc++ OTHER_LDFLAGS=-stdlib=libc++
to the end of the xcodebuild
line. This will force xcodebuild to do the right thing.
If your application is built with GCC and GNU libstdc++, you don't need to add anything to the xcodebuild
line.