MinGW Woes

[3hM2Nwbp]

I get so frustrated with the GNU websites anymore...I cannot find ANYWHERE the version of the compiler that I'm going to be downloading. So I download the automated installer (by clicking "Get Latest Version" and run it, it downloads a few dozen files, and seemingly "finishes" installing the latest version of the GCC port.

I still can't compile lambda expressions and can't find the G++ version anywhere in the installation directory. Isn't that...kind of important to be able to find?? Can anyone give some command-line-fu with the compiler so I can figure out exactly what was installed? It's simply not intuitive in my mindset...

Guess that's what I get for trying to upgrade. Frustratin-G++.

* Additional Question(s)
It appears that the latest GCC Version is 4.7 - is there even a minGW port for this?

[helios]

Uhh... g++ --version?

And serves you right for being an early adopter.

[3hM2Nwbp]

Thanks for the reply.

I was wondering why
-version
/version
-ver
/ver

etc weren't working. Who'd have thought of using two dashes?

I guess it installed 4.5.2

[helios]

Whenever dealing with GNU software, remember to use - for short options and -- for long options.

[S6k9GNh0]

lamda expressions are part of C++0x I think. In order to use them with GCC, you must pass the --std=c++0x or std=gnu++0x parameter. Same goes for auto, and various other C++0x features.

[3hM2Nwbp]

Thanks for the info - but I found out why I wasn't able to use lambda expressions. Code::Blocks was using the wrong installation (still the older one). That's resolved...however it looks like the mingw port of GCC 4.5.2 still doesn't support the `nullptr` keyword. At this point I'm assuming that 4.5.2 is the latest mingw version supported (as that's what was downloaded when I clicked the "get latest version" link).

It's surprising to see how much (C++0x) code breaks when I try to compile it with g++ instead of Microsoft's compiler.

[S6k9GNh0]

Like what exactly? Lamda expressions work fine over here.

I am however experiencing a bug with Boost.Spirit where 4.5.2 crashes on compile. However, this happens just as often with other compilers so I'm told.

[3hM2Nwbp]

Mostly places where nullptr is used. I've just set up a macro for it. There are a lot of warnings that I've not seen before, but they'll have to wait for tomorrow. There are a few other issues I need to test as well. The older mingw installation crashes with boost::asio and I'm getting some link errors while trying to build boost::thread. Hopefully the newer installation will resolve those.

[S6k9GNh0]

Boost Thread, by default, uses the shared library with GCC, unlike VC++. Don't ask me, it's just how it is. As a result, a macro (BOOST_THREAD_USE_LIB) must be applied. Although, the config.hpp file also hints that GCC doesn't support auto-tss cleanup (whatever that is) which is why it defaults to using the shared library. If I'm not mistaken, std::thread is already implemented in libstdc++, so you can use that as well.

I also don't use Boost.ASIO and instead use header-based ASIO. It includes a header-based minimal thread model similar to Boost's, implements it's own exception class, and has no link dependencies. It still requires Boost headers however. When developing a library, it's much easier on the user of the library since otherwise, they'd have to download, compile, and link to Boost.System which in my opinion was simply not worth it (a 10 minute compile time just for an exception handling class is bullshit). I also looked into forcing unresolved symbols without much hope.

EDIT: Also, it's just a matter of where to look. I know that mingw-get is the tool used to download and install MinGW and Msys. Looking at the changelog, you can see the latest version. However, finding the changelog was a challenge. For some reason, they don't provide package version numbers in the catalog for you to see. They do, they just don't let you see them. It is a system that needs much work. 4.5.2 is the latest port of GCC MinGW has released on the stable list (er, actually, I think anything in the 4.x series is considered experimental where 3.x is considered stable).