Closed GoogleCodeExporter closed 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
This happens with MSYS+MinGW as well.
Original comment by isak.joh...@gmail.com
on 6 May 2008 at 12:14
Are you 'using' the breakpad namespaces?
Original comment by neal...@gmail.com
on 27 Feb 2009 at 1:46
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
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:
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
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
This is fixed in r751.
Original comment by ted.mielczarek
on 11 Jan 2011 at 8:29
Original comment by ted.mielczarek
on 28 Jan 2011 at 2:37
Original issue reported on code.google.com by
j...@mac.com
on 23 Nov 2007 at 2:00