MinGW-builds: argh!

[DrMrLordX]

Note: I'm doing all this in Win10 10130 so . . . if that's part of the problem, then I'll just have to ignore MinGW until it decides to behave itself. I've got VS Express 2013 for Windows Desktop downloading right now so I'll go with that until I need MinGW for some reason.

It's time to get back on the old C/C++ horse and do some awkward riding. Sadly, just setting up the desired toolchain is causing headaches.

I snagged MinGW-builds and had it install MinGW-w64 (x86_64-5.1.0-win32-seh-rt_v4-rev0) without msys. Eclipse couldn't find it, so I had to do some fiddling with project properties to get it to find MinGW. Then I had to explicitly point it to the proper directory just so I could #include <iostream> without compiler warnings. It seems like Eclipse CDT is (mostly) behaving itself now. But MinGW itself is not. Here's the obligatory "hello world":

#include <iostream>
using namespace std;

int main()
{
  cout >> "Hello World . . . again.";
}

Attempting a build in Eclipse produced many, many errors, so I tried it from command-line with a simple "g++ CPPLearning.cpp" and also with the switches used in Eclipse by default (-O2 -g -Wall -c -fmessage-length=0). I got the same errors. Example:

CPPLearning.cpp: In function 'int main()':
CPPLearning.cpp:13:8: error: no match for 'operator>>' (operand types are 'std::ostream {aka std::basic_ostream<char>}' and 'const char [25]')
   cout >> "Hello World . . . again.";
        ^
In file included from C:/Program Files/mingw-w64/x86_64-5.1.0-win32-seh-rt_v4-rev0/mingw64/x86_64-w64-mingw32/include/c++/string:53:0,
                 from C:/Program Files/mingw-w64/x86_64-5.1.0-win32-seh-rt_v4-rev0/mingw64/x86_64-w64-mingw32/include/c++/bits/locale_classes.h:40,
                 from C:/Program Files/mingw-w64/x86_64-5.1.0-win32-seh-rt_v4-rev0/mingw64/x86_64-w64-mingw32/include/c++/bits/ios_base.h:41,
                 from C:/Program Files/mingw-w64/x86_64-5.1.0-win32-seh-rt_v4-rev0/mingw64/x86_64-w64-mingw32/include/c++/ios:42,
                 from C:/Program Files/mingw-w64/x86_64-5.1.0-win32-seh-rt_v4-rev0/mingw64/x86_64-w64-mingw32/include/c++/ostream:38,
                 from C:/Program Files/mingw-w64/x86_64-5.1.0-win32-seh-rt_v4-rev0/mingw64/x86_64-w64-mingw32/include/c++/iostream:39,
                 from CPPLearning.cpp:8:
C:/Program Files/mingw-w64/x86_64-5.1.0-win32-seh-rt_v4-rev0/mingw64/x86_64-w64-mingw32/include/c++/bits/basic_string.tcc:1441:5: note: candidate: template<class _CharT, class _Traits, class _Alloc> std::basic_istream<_CharT, _Traits>& std::operator>>(std::basic_istream<_CharT, _Traits>&, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&)
     operator>>(basic_istream<_CharT, _Traits>& __in,
     ^

That just goes on and on with more and more errors. I can paste the entire thing if you want to see it.

Regardless, the errors are a bit frustrating and confusing. I'd like to have MinGW available so I can at least test my code in a different compiler to see how well it runs there vs VS2013. The other option is to cross-compile from Linux. I'd prefer to do my coding and compiling for Windows in Windows if possible.

 

[Cogman]

You're going to kick yourself, but it should be

cout << "Hello world again";

Your chevrons are going the wrong way (that is what the error message is pointing out.).

 

[DrMrLordX]

Wow. Really? Horrible. I can see this effort will go well.

Eclipse is still being stupid post correction (symbol 'cout' could not be resolved) but at least I'm getting fewer errors. At least g++ works at the command line now. Bleh.