MinGW build does not compile with C++11

Resurrecting a slightly old topic here, but this is affecting one of
our build bots. It would be nice if we made a decision here and either
fixed that bot, or drop MinGW32 support. I don't have a strong opinion
one way or the other, but a terminally red bot is a sad bot indeed.

http://lab.llvm.org:8011/builders/clang-native-mingw32-win7

~Aaron

According to c++ - Mingw g++ does not recognize off_t when compiling with c++11 - Stack Overflow
it should be possible to use gnu++11 on mingw. Is that sufficient to
build llvm+clang?

Cheers,
Rafael

Honestly not certain (I don't build using MinGW), but I'd say it's
worth a shot if the owner of that bot could apply it to see. It seems
possible that it may bring the bot back into green.

~Aaron

Mira Fontan later responded that after switching to mingw-builds the build was ok, so if we also switch the bot to the mingw-build distribution it may start working again. That’s not the only reason for switching, the minge-builds distribution supports 64 bit code production which mingw.org does not and gets updated more often.

The actual build is somewhat hard to find, for WIN32, start with

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.2/

and follow links based on threads and exception types.

For WIN64, start here

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.2/

Yaron

Galina, can you give it a try?

Thanks,
Rafael

I think the entire point of that bot is to test MinGW32, not MinGW64,
which is why I brought this up. We already have coverage for MinGW64:

http://bb.pgr.jp/builders/ninja-clang-x64-mingw64-RA

So if we switch this bot to MinGW64, while leaving MinGW32 broken, are
we going to explicitly say we do not support MinGW32?

~Aaron

Aaron Ballman <aaron@aaronballman.com> writes:

Mira Fontan later responded that after switching to mingw-builds the build
was ok, so if we also switch the bot to the mingw-build distribution it may
start working again. That's not the only reason for switching, the
minge-builds distribution supports 64 bit code production which mingw.org
does not and gets updated more often.

I think the entire point of that bot is to test MinGW32, not MinGW64,
which is why I brought this up. We already have coverage for MinGW64:

http://bb.pgr.jp/builders/ninja-clang-x64-mingw64-RA

That's only the 64 bit compiler of MinGW-W64. That project also
publishes a 32 bit compiler, which is what Yaron proposes to use instead
of the compiler provided by mingw.org, IIUC. I concur with him, FWIW.

So if we switch this bot to MinGW64, while leaving MinGW32 broken, are
we going to explicitly say we do not support MinGW32?

IMO switching from mingw.org to mingw-w64 as the 32 bit MinGW toolset
makes sense, for the reasons given by Yaron.

It is. I recently ran into this problem and patching with the following allows
a full build of LLVM/Clang for i686-mingw32 host (GCC 4.7.2):

--- Makefile.rules (revision 203598)
+++ Makefile.rules (working copy)
@@ -322,7 +322,13 @@ endif
ifeq ($(ENABLE_CXX1Y),1)
   CXX.Flags += -std=c++1y
else
- CXX.Flags += -std=c++11
+ ifeq ($(HOST_OS),MingW)
+ # MinGW is a bit stricter and lacks things like
+ # 'strdup', 'stricmp', etc...
+ CXX.Flags += -std=gnu++11
+ else
+ CXX.Flags += -std=c++11
+ endif
endif

I am happy to apply the above if others are OK with it.
I am currently interested in using mingw32.

So if we switch this bot to MinGW64, while leaving MinGW32 broken, are
we going to explicitly say we do not support MinGW32?

IMO switching from mingw.org to mingw-w64 as the 32 bit MinGW toolset
makes sense, for the reasons given by Yaron.

+1

It is. I recently ran into this problem and patching with the following allows
a full build of LLVM/Clang for i686-mingw32 host (GCC 4.7.2):

--- Makefile.rules (revision 203598)
+++ Makefile.rules (working copy)
@@ -322,7 +322,13 @@ endif
ifeq ($(ENABLE_CXX1Y),1)
   CXX.Flags += -std=c++1y
else
- CXX.Flags += -std=c++11
+ ifeq ($(HOST_OS),MingW)
+ # MinGW is a bit stricter and lacks things like
+ # 'strdup', 'stricmp', etc...
+ CXX.Flags += -std=gnu++11
+ else
+ CXX.Flags += -std=c++11
+ endif
endif

I am happy to apply the above if others are OK with it.
I am currently interested in using mingw32.

We should change cmake too I think.

Would anyone object to applying the patch to keep mingw32 working?
Even if we make mingw-w64 the preferred solution, that is such a small
patch I wouldn't have a problem with it.

Cheers,
Rafael

I am happy to apply the above if others are OK with it.
I am currently interested in using mingw32.

We should change cmake too I think.

Would anyone object to applying the patch to keep mingw32 working?
Even if we make mingw-w64 the preferred solution, that is such a small
patch I wouldn't have a problem with it.

The change looks fine to me as well. And certainly, we need to have
cmake version of this.

FYI, it is also applicable to cygwin.
http://llvm.org/bugs/show_bug.cgi?id=18847

I suggest to check non-ansi functionalities with both -std=c++11 and
-std=gnu++11 in configure.
IMHO, for now, we could use -std=gnu++11 until the source tree became
c++11-compliant.

We should probably not use gnu++11 where we don't need it. The
attached patch is a blind attempt at fixing this for cmake too. I have
only tested that we still use c++11 on linux with it :slight_smile:

Cheers,
Rafael

t.patch (1.29 KB)

I tested this locally on cygwin and mingw. I committed it as r203701.
Lets see if it makes the bots happy.

Yes, I ran into this on both 32-bit and 64-bit Cygwin.
I had to change two files:

llvm/Makefile.rules
llvm/projects/sample/Makefile.llvm.rules

Thanks!

Hello everyone,

I have un-defined STRICT_ANSI for MinGW32 builder.

This fixed the issue.

In general, maybe we should define our own types to be within the strict ansi range, if this is what we want?
Though, this wouldn’t fix the issue with 3-rd party code in the test suite.

Thanks

Galina