search

bgreen0 / google-breakpad

Automatically exported from code.google.com/p/google-breakpad
0 stars 0 forks source link

Using Breakpad Windows Libray files with Qt application, produces the following error: main.obj:-1: error: LNK2019: unresolved external symbol google_breakpad::ExceptionHandler::ExceptionHandler.... #536

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

1. Using settings for all 11 projects that make up the breakpad_client Solution 
in configuration settings: C/C++ Language "Treat WChar_t As built in Type set 
to "No(/Zc:wchar_t-) and under C/C++ Code Generation Runtime Library  
"Multi-threaded Debug(/MTd)"

2. Build breakpad_client Solution file in Microsoft Visual C++ 
Build succeeded on all 11 projects.

3. In Qt build the application, LNK2019  error appears.

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

The creation of the .dmp file from a function that simulates a crash.

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

OS: Windows 7 Professional 64 bit edition

To build the breakpad_client libraries

Microsoft Visual C++ 10 Version: 10.0.30319 RTMRel
Microsoft .NET Framework Version 4.0.30319 RTMRel

Active Solution Confederation: Debug 
Active Solution platform: Win32

Compiler: Microsoft Visual C++ Compiler 10.0 (x86)

Compiling and Running the application

Qt Creator 2.7.1
based on Qt 4.8.4(32 bit)

Using compiler Microsoft Visual C++ Compiler 10.0 x86

Please provide any additional information below.

The code below is where the error occurs

std::wstring pathAsStr = (const wchar_t*)pwd.utf16();

static google_breakpad::ExceptionHandler* handler;

    handler = new google_breakpad::ExceptionHandler
            (
                pathAsStr,
                /*FilterCallback*/ 0,
                dumpCallback,
                /*context*/
                0,
                true
                );

Error output in Full:

main.obj:-1: error: LNK2019: unresolved external symbol "public: __cdecl 
google_breakpad::ExceptionHandler::ExceptionHandler(class 
std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class 
std::allocator<unsigned short> > const &,bool (__cdecl*)(void *,struct 
_EXCEPTION_POINTERS *,struct MDRawAssertionInfo *),bool (__cdecl*)(unsigned 
short const *,unsigned short const *,void *,struct _EXCEPTION_POINTERS *,struct 
MDRawAssertionInfo *,bool),void *,int)" 
(??0ExceptionHandler@google_breakpad@@QEAA@AEBV?$basic_string@GU?$char_traits@G@
std@@V?$allocator@G@2@@std@@P6A_NPEAXPEAU_EXCEPTION_POINTERS@@PEAUMDRawAssertion
Info@@@ZP6A_NPEBG5123_N@Z1H@Z) referenced in function main

File not found main.obj

Original issue reported on code.google.com by saul.lue...@gmail.com on 17 Jul 2013 at 1:01

GoogleCodeExporter commented 9 years ago 
Please note I had already changed the setting  "Treat WChar_t As built in Type" 
and set it to "No(/Zc:wchar_t-") in Microsoft Visual C++ 2010 Express, Despite 
this I'm still presented with the same error when compiling my application. I 
had also tried to set the runtime library to "Multi-threaded Debug DLL(/MDd), 
this caused the breakpad client libraries to fail to build.

Original comment by saul.lue...@gmail.com on 17 Jul 2013 at 1:29

GoogleCodeExporter commented 9 years ago 
Found any solutions to this? I'm having the same problem.

Original comment by njitrams...@gmail.com on 10 Aug 2013 at 9:24

GoogleCodeExporter commented 9 years ago 
Can you locate exception_handler.obj, run "dumpbin -symbols" on it, and grep 
for ExceptionHandler::ExceptionHandler? Here's the (demangled) output from my 
local copy:
__thiscall google_breakpad::ExceptionHandler::ExceptionHandler(class 
std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class 
std::allocator<wchar_t> > const &,bool (__cdecl*)(void *,struct 
_EXCEPTION_POINTERS *,struct MDRawAssertionInfo *),bool __cdecl*)(wchar_t const 
*,wchar_t const *,void *,struct _EXCEPTION_POINTERS *,struct MDRawAssertionInfo 
*,bool),void *,int))

The notable differences are that mine is __thiscall instead of the _cdecl yours 
is looking for, and mine uses wchar_t instead of unsigned long (unsurprising if 
you've fiddled the wchar_t-as-built-in-type setting). I suspect you've simply 
got some compiler setting mismatch between your code and the Breakpad projects 
that causes the signatures to not match.

Original comment by ted.mielczarek on 14 Aug 2013 at 11:42