[Bug bootstrap/60050] New: Build failure on MinGW64

[Bug bootstrap/60050] New: Build failure on MinGW64

[p.fedin at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60050

            Bug ID: 60050
           Summary: Build failure on MinGW64
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: p.fedin at samsung dot com

gcc fails to natively build for MinGW64 platform:
--- cut ---
make[3]: Entering directory `/usr/src/gcc-4.8.2/host-x86_64-w64-mingw32/gcc'
g++ -c  -DPREFIX=\"/mingw\" -DBASEVER="\"4.8.2\"" -g -DIN_GCC   -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual
-Wmissing-format-attrib
ute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/.
-I../.././gcc/../include -I../.././gcc
/../libcpp/include  -I../.././gcc/../libdecnumber
-I../.././gcc/../libdecnumber/bid -I../libdecnumber
-I../.././gcc/../libbacktrace    ../.././gcc/prefix.c -o prefix.o
In file included from
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include/urlmon.h:219:0,
                 from
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include/objbase.h:325,
                 from
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include/ole2.h:16,
                 from
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include/windows.h:97,
                 from ../.././gcc/prefix.c:70:
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include/msxml.h:636:38:
error: macro "abort" passed 1 arguments, but takes just 0
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include/msxml.h:2669:38:
error: macro "abort" passed 1 arguments, but takes just 0
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include/msxml.h:636:42:
error: ISO C++ forbids initialization of member 'abort' [-fpermissive]
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include/msxml.h:636:42:
error: making 'abort' static [-fpermissive]
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include/msxml.h:636:42:
error: ISO C++ forbids in-class initialization of non-const static member
'abort'
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include/msxml.h:636:42:
error: 'abort' declared as a 'virtual' field
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include/msxml.h:2669:42:
error: ISO C++ forbids initialization of member 'abort' [-fpermissive]
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include/msxml.h:2669:42:
error: making 'abort' static [-fpermissive]
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include/msxml.h:2669:42:
error: ISO C++ forbids in-class initialization of non-const static member
'abort'
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include/msxml.h:2669:42:
error: 'abort' declared as a 'virtual' field
make[3]: *** [prefix.o] Error 1
make[3]: Leaving directory `/usr/src/gcc-4.8.2/host-x86_64-w64-mingw32/gcc'
make[2]: *** [all-stage1-gcc] Error 2
--- cut ---
 This problem is present since v4.8 i believe (i tried also 4.8.1). Actually,
this happens because of this sequence in prefix.c:
--- cut ---
#include "config.h"
#include "system.h"
#include "coretypes.h"
#if defined(_WIN32) && defined(ENABLE_WIN32_REGISTRY)
#include <windows.h>
#endif
--- cut ---
 In system.h we have this:
--- cut ---
/* Redefine abort to report an internal error w/o coredump, and
   reporting the location of the error in the source file.  */
extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN;
#define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
--- cut ---
 And after that we attempt to #include <windows.h> in C++ mode, because we use
g++ in order to compile this .c file (why ?). In msxml.h "abort(void)" is a
member of IXMLDOMDocument interface:
--- cut ---
#if defined(__cplusplus) && !defined(CINTERFACE)
  struct IXMLDOMDocument : public IXMLDOMNode {
  public:
    virtual HRESULT WINAPI get_doctype(IXMLDOMDocumentType **documentType) = 0;
    virtual HRESULT WINAPI get_implementation(IXMLDOMImplementation **impl) =
0;
    virtual HRESULT WINAPI get_documentElement(IXMLDOMElement **DOMElement) =
0;
    virtual HRESULT WINAPI putref_documentElement(IXMLDOMElement *DOMElement) =
0;
    virtual HRESULT WINAPI createElement(BSTR tagName,IXMLDOMElement **element)
= 0;
    virtual HRESULT WINAPI createDocumentFragment(IXMLDOMDocumentFragment
**docFrag) = 0;
    virtual HRESULT WINAPI createTextNode(BSTR data,IXMLDOMText **text) = 0;
    virtual HRESULT WINAPI createComment(BSTR data,IXMLDOMComment **comment) =
0;
    virtual HRESULT WINAPI createCDATASection(BSTR data,IXMLDOMCDATASection
**cdata) = 0;
    virtual HRESULT WINAPI createProcessingInstruction(BSTR target,BSTR
data,IXMLDOMProcessingInstruction **pi) = 0;
    virtual HRESULT WINAPI createAttribute(BSTR name,IXMLDOMAttribute
**attribute) = 0;
    virtual HRESULT WINAPI createEntityReference(BSTR
name,IXMLDOMEntityReference **entityRef) = 0;
    virtual HRESULT WINAPI getElementsByTagName(BSTR tagName,IXMLDOMNodeList
**resultList) = 0;
    virtual HRESULT WINAPI createNode(VARIANT Type,BSTR name,BSTR
namespaceURI,IXMLDOMNode **node) = 0;
    virtual HRESULT WINAPI nodeFromID(BSTR idString,IXMLDOMNode **node) = 0;
    virtual HRESULT WINAPI load(VARIANT xmlSource,VARIANT_BOOL *isSuccessful) =
0;
    virtual HRESULT WINAPI get_readyState(long *value) = 0;
    virtual HRESULT WINAPI get_parseError(IXMLDOMParseError **errorObj) = 0;
    virtual HRESULT WINAPI get_url(BSTR *urlString) = 0;
    virtual HRESULT WINAPI get_async(VARIANT_BOOL *isAsync) = 0;
    virtual HRESULT WINAPI put_async(VARIANT_BOOL isAsync) = 0;
    virtual HRESULT WINAPI abort(void) = 0;
--- cut ---
 This causes the conflict. A solution is to add a #define CINTERFACE to
prefix.c right before #include <windows.h>.
 gcc v4.7 did not suffer from this problem because 'gcc' was used at this stage
instead of 'g++'.

[Bug bootstrap/60050] Build failure on MinGW64

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60050

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |ktietz at gcc dot gnu.org
         Resolution|---                         |INVALID

--- Comment #1 from Kai Tietz <ktietz at gcc dot gnu.org> ---
This bug was fixed on mingw-w64's side.  It isn't a gcc-bug.  Btw gcc 4.6 isn't
under maintenance anymore.

[Bug bootstrap/60050] Build failure on MinGW64

[sje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60050

Steve Ellcey <sje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sje at gcc dot gnu.org

--- Comment #2 from Steve Ellcey <sje at gcc dot gnu.org> ---
I know this isn't a GCC bug but could we include a pointer here to what change
wingw-w64 made to fix this problem?  I have been searching around to find out
and cannot find any reference to the problem or fix other than this defect
report.

[Bug bootstrap/60050] Build failure on MinGW64

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60050

--- Comment #3 from Kai Tietz <ktietz at gcc dot gnu.org> ---
we took care that gcc's abort-redefinition doesn't break the platform-internal
use.
For further information take a look to mingw-w64's headers.  This is the wrong
place to discuss that.