alexhe / google-breakpad

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

logging.h re-defines SEVERITY_ERROR #228

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
There's a name conflict in the file src/processor/logging.h when compiling on 
Windows:

The name SEVERITY_ERROR is used in the Windows APIs as a macro (in 
<winerror.h>), so the usage 
of this name in en enumeration will result in compiler errors when trying to 
compile some of the 
source files on Windows.

The obvious solution is to use a different name for this enumeration value (I 
don't think just 
#undef'ing the macro is a proper solution).

Original issue reported on code.google.com by j...@mac.com on 23 Nov 2007 at 2:00

GoogleCodeExporter commented 9 years ago
Sorry, should have mentioned that this is when using VisualStudio 2005. Not 
sure whether the problem exists, 
when using other compilers on Windows...

Original comment by j...@mac.com on 23 Nov 2007 at 2:25

GoogleCodeExporter commented 9 years ago
This happens with MSYS+MinGW as well.

Original comment by isak.joh...@gmail.com on 6 May 2008 at 12:14

GoogleCodeExporter commented 9 years ago
Are you 'using' the breakpad namespaces? 

Original comment by neal...@gmail.com on 27 Feb 2009 at 1:46

GoogleCodeExporter commented 9 years ago
I don't think this is a matter of namespaces, since SEVERITY_ERROR is defined 
as a _macro_ in the Windows API 
header files...

Original comment by j...@mac.com on 27 Feb 2009 at 9:23

GoogleCodeExporter commented 9 years ago
I also tried to build processor with MinGW+MSys, and to hack the sources a 
little 
to avoid these errors. The lucky part for me is I just simply get it compiled 
into .o, 
but I can't get it linked to an .exe. Following is my error msg:

================
libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared 
libraries
src/processor/.libs/minidump.o: In function 
`ZNSt14basic_ifstreamIcSt11char_traitsIcEE5_openEPKcSt13_Ios_Openmode':

c:/mingw/bin/../lib/gcc/mingw32/4.4.0/include/c++/fstream:527: undefined 
reference to `std::basic_filebuf<char, std::char_traits<char> >::_open(char 
const*, 
std::_Ios_Openmode)'

src/processor/.libs/minidump.o:e:\OpenSource\bp/src/processor/minidump.cc:363
6: undefined reference to `std::istream::_read(char*, int)'

collect2: ld returned 1 exit status

make: *** [src/processor/minidump_dump.exe] Error 1
===========

The attach is my patch, and I have to say it's really a dirty hack that I only 
tried to 
solve one problem at a time.

Hope someone can find a solution from here.

Original comment by frank28 on 10 Dec 2009 at 12:42

Attachments:

GoogleCodeExporter commented 9 years ago
I finally got it to compile with MinGW+MSYS, thanks in large part to the patch. 
 Frank:  
you need to comment out lines 45 and 46 in minidump.cc.

So:
//#define open _open
//#define read _read

I don't know why those defines are there to begin with but it prevents proper 
linkage

Original comment by ctrlaltd...@gmail.com on 21 Jan 2010 at 7:23

GoogleCodeExporter commented 9 years ago
Those defines were there because that file used to use libc file I/O functions. 
It was switched at some point to use C++ file I/O, but those weren't removed.

Original comment by ted.mielczarek on 23 Sep 2010 at 5:41

GoogleCodeExporter commented 9 years ago
This is fixed in r751.

Original comment by ted.mielczarek on 11 Jan 2011 at 8:29

GoogleCodeExporter commented 9 years ago

Original comment by ted.mielczarek on 28 Jan 2011 at 2:37