57

In the MinGW-W64 online installer there are several fields you can select. However I cannot find any documentation on this, and the guesses I've made don't give me the behaviour I want.

Clearly a lot of work has gone into this project so it seems a pity that uptake is being held back by lack of basic documentation.

The "Version" and "Architecture" fields are self-explanatory but the other fields I have trouble with are (values shown as of current installer):

  • Threads, options posix and win32
  • Exception, options dwarf and sjlj
  • Build revision, options 0, 1, 2.

The values I chose on my previous install were win32, seh and 1 (clearly the options have changed since then but I am none the wiser as to what's what).

What are the pros and cons of each option, especially the threading model and exception handling, and which version is "best"?

The specific problems I have encountered using x86_64-win32-seh-rev1 are:

  • std::thread and std::condition_variable are not supported
  • When debugging (using Code::Blocks as IDE), if an exception is thrown it does not jump to the exception handler; selecting Next Line does nothing 3 times and then aborts the run.

I can cope with the debugging problem but it would be really nice to have working C++11 threads.

M.M
  • 130,300
  • 18
  • 171
  • 314
  • 1
    Update. Have noticed that `std::thread` etc. is hidden behind `_GLIBCXX_HAS_GTHREADS` which is not defined by my installation of mingw-w64 – M.M Apr 30 '15 at 12:53
  • Don't define this yourself - it's enabled if you link *pthread*'s. – ollo May 11 '15 at 22:39
  • 1
    For anyone else reading this: when using `win32` threads, [this project](https://github.com/meganz/mingw-std-threads) enables C++11 threads, mutexes and condition_variable and it seems to work! – M.M May 12 '15 at 01:00

1 Answers1

34

Exceptions

Please see this answer for all three models (dwarf, sjlj and seh).

Threads

You can decide what kind of threads you want to use: POSIX threads or Windows API threads. The posix threads have the advantage of portability; you can use your code on other posix platforms (eg. linux) without modifications. The win32 threading api is windows only. If you are 100% on windows and like it's api that's no problem though.

If you use new C++ features like std::thread the impact is less visible since you already have a standard api for threading. I'm not sure if there's really a big difference if you don't use posix- / win32 thread api directly (maybe std::thread native handles?)

See also: mingw-w64 threads: posix vs win32

Build revision

I guess that's just another version number since Mingw(-w64) follows GCC versions (4.8.x, 4.9.x etc.). If you don't need an specific build, you should use the latest version.

Threading issue

If the exception thrown is:

terminate called after throwing an instance of 'std::system_error'
  what():  Enable multithreading to use std::thread: Operation not permitted

then just link pthreads - and the problem is solved.

Recommendation

If you don't have reasons to use a specific option; my personal recommendation:

posix - dwarf - 2
  • Posix enable C++11 <thread>, <mutex> and <future>
  • dwarf is faster
  • 2 because it's the latest release
Community
  • 1
  • 1
ollo
  • 23,119
  • 13
  • 93
  • 146
  • 2
    Thanks for the detailed answer. The question you link to about exception handling says that `dwarf` doesn't work in 64-bit though (and I am targeting 64-bit Windows). Has it been improved since that answer was written? – M.M May 12 '15 at 01:01
  • Regarding threading, I intend to use C++11 threads; and not use the pthread API directly. I guess I should jack up some sort of performance test between the pthreads option; and the win32 option with the [meganz addon](https://github.com/meganz/mingw-std-threads). – M.M May 12 '15 at 01:03
  • **Threading:** With C++11 threading api you can even change later - the underlying model is abstracted very well. So finally it seems a performance / personal preference decision to me - with the option to switch anytime! Btw. would be cool if you could share your results. – ollo May 12 '15 at 15:46
  • **Exception:** I think it's more a compatibility problem. If your program uses dwarf while windows libs (eg. VC++ build) throws an exception, it propagates through your dwarf exception code. If you use much libraries that are not dwarf-aware but may throw exceptions, better use sjlj. If you have only nonthrowing libs or darf-aware ones that should work - in my view. – ollo May 12 '15 at 15:53
  • 2
    OK. I see now that the mingw-w64 installer changes its options once you select target type; so if `x86_64` is selected then the only two options are `sjlj` as `seh`. So it looks like it is a choice between slow and debugger-fail. Perhaps I will post a new question about the debugging issue with seh. – M.M May 12 '15 at 21:47
  • "Posix threads are more portable": the libgcc internal threading API has absolutely no influence on portability: you can just as well call pthreads functions with a win32-threading GCC. I modified your answer for correctness. – rubenvb May 22 '15 at 06:52
  • I see two other options for x86 seh and sjlj, I'm using windows 64bit, which one should I use? @ollo – Akhila Nov 29 '20 at 20:26