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.
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
Related
I started to use C++11 std::thread (mingw 4.8) so far so good. I ran into a situation with overlapped I/O where sleepEx was used to put the thread in an alertable wait state. This worked quite well, until QueueUserAPC had to be used, which returned an "invalid handle error".
After some searching found out that std::thread uses the pthread library under Windows.
Is there any way to use windows API calls which expect a thread handle with std::thread ?
Or do I need to stick with Windows threads for overlapped I/O ?
To solve your issue, MinGW-w64 winpthreads (the pthreads implementation you are using), just like pthreads-win32, allows you to get the native Win32 thread handle for a pthread:
void * pthread_gethandle (pthread_t t);
Note that this is currently an undocumented function.
The corresponding function in pthreads-win32 is:
HANDLE pthread_getw32threadhandle_np(pthread_t thread);
I'd bet this will make your intermixing of the two work, or at least bring to light some bugs in winpthreads which can be fixed. In the latter case, please report them to MinGW-w64.
If the above returns an invalid handle, your best bet is to ask on the MinGW-w64-public mailing list (subscribe first, otherwise you'll have to wait for manual moderation which is silly).
Is there any way to use windows API calls which expect a thread handle with std::thread ?
No, because the std::thread in your MinGW build isn't implemented in terms of thread handles. Edit: it is, but indirectly, see rubenvb's answer for how to get the native thread handle from a pthread_t, and you should be able to use std::thread::native_handle() to get the pthread_t.
Noone has implemented the necessary support in GCC for the C++11 thread library to use native Windows threads directly.
I had some ideas for a new thead model that would be implemented in terms of native mutexes and condition variables. That would allow you to call std::thread::native_handle() to get the underlying thread handle to use with the Windows API.
I got as far as rebuilding GCC with my changes applied, but couldn't test them. There was almost no interest in my suggestions and no offers to help from any MinGW contributors, so as I'm not a Windows user, and working on Windows and building MinGW was so painful and frustrating, I gave up. I should put my changes online somewhere, so that someone with more patience than me can finish the work one day.
There is already a native win32 implementation of std::thread and sync primitives, see:
https://github.com/meganz/mingw-std-threads
This is a header-only library and works with any version of MinGW that has proper language support for C++11
I'm installing mingw-w64 on Windows and there are two options: win32 threads and posix threads. I know what is the difference between win32 threads and pthreads but I don't understand what is the difference between these two options. I doubt that if I will choose posix threads it will prevent me from calling WinAPI functions like CreateThread.
It seems that this option specify which threading API will be used by some program or library, but by what? By GCC, libstdc++ or by something else?
I found this:
Whats the difference between thread_posixs and thread_win32 in gcc port of windows?
In short, for this version of mingw, the threads-posix release will use the posix API and allow the use of std::thread, and the threads-win32 will use the win32 API, and disable the std::thread part of the standard.
Ok, if I will select win32 threads then std::thread will be unavailable but win32 threads will still be used. But used by what?
GCC comes with a compiler runtime library (libgcc) which it uses for (among other things) providing a low-level OS abstraction for multithreading related functionality in the languages it supports. The most relevant example is libstdc++'s C++11 <thread>, <mutex>, and <future>, which do not have a complete implementation when GCC is built with its internal Win32 threading model. MinGW-w64 provides a winpthreads (a pthreads implementation on top of the Win32 multithreading API) which GCC can then link in to enable all the fancy features.
I must stress this option does not forbid you to write any code you want (it has absolutely NO influence on what API you can call in your code). It only reflects what GCC's runtime libraries (libgcc/libstdc++/...) use for their functionality. The caveat quoted by #James has nothing to do with GCC's internal threading model, but rather with Microsoft's CRT implementation.
To summarize:
posix: enable C++11/C11 multithreading features. Makes libgcc depend on libwinpthreads, so that even if you don't directly call pthreads API, you'll be distributing the winpthreads DLL. There's nothing wrong with distributing one more DLL with your application.
win32: No C++11 multithreading features.
Neither have influence on any user code calling Win32 APIs or pthreads APIs. You can always use both.
Parts of the GCC runtime (the exception handling, in particular) are dependent on the threading model being used. So, if you're using the version of the runtime that was built with POSIX threads, but decide to create threads in your own code with the Win32 APIs, you're likely to have problems at some point.
Even if you're using the Win32 threading version of the runtime you probably shouldn't be calling the Win32 APIs directly. Quoting from the MinGW FAQ:
As MinGW uses the standard Microsoft C runtime library which comes with Windows, you should be careful and use the correct function to generate a new thread. In particular, the CreateThread function will not setup the stack correctly for the C runtime library. You should use _beginthreadex instead, which is (almost) completely compatible with CreateThread.
Note that it is now possible to use some of C++11 std::thread in the win32 threading mode. These header-only adapters worked out of the box for me:
https://github.com/meganz/mingw-std-threads
From the revision history it looks like there is some recent attempt to make this a part of the mingw64 runtime.
#rubenvb answer is fully correct, use the mingw posix compiler if you want to use std::thread, std::mutex, etc. For everybody who is using CMake, here is an example:
set(CMAKE_CXX_STANDARD 17) # or 20 if you want..
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(THREADS_PREFER_PTHREAD_FLAG ON)
set(TOOLCHAIN_PREFIX x86_64-w64-mingw32)
set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}-gcc-posix)
set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}-g++-posix)
set(CMAKE_RC_COMPILER ${TOOLCHAIN_PREFIX}-windres)
set(CMAKE_FIND_ROOT_PATH
/usr/${TOOLCHAIN_PREFIX}
)
Ideal for cross-compiling Linux apps to Windows.
Hint: For people who are using GTK3 and want to cross-compile their GTK application to Windows. You maybe want to download the Mingw Windows GTK bundle, downloaded and packaged from msys2.org so you don't need to: https://gitlab.melroy.org/melroy/gtk-3-bundle-for-windows
I'm new to programming Linux kernel modules, and many getting started guides on the topic include little information about how to build a kernel module which will run on many versions and CPU platforms of Linux. Most of the guides I've seen simply state things like, "Linux doesn't ensure any ABI/API compatibility between versions." However, other OSes do provide these guarantees for major versions, and the guides are mostly targeting 2.7 (which is a bit old now).
I was wondering if there is any kind of ABI/API compatibility now, or if there are any standard ways to deal with versioning other than isolating the kernel-dependent bits of my code into files with a ton of preprocessor directives. (Also, are there any standard preprocessor symbols I should be using in the second case?)
There isn't a stable ABI for the kernel and most likely never will be because it'd make Linux suck. The reasons for not having one are all pretty much documented in that link.
The best way to deal with this is to get your driver merged upstream where it'll be maintained by other kernel developers.
As to being cross-platform, that pretty much comes free with the Linux kernel as long as you only use the standard, platform-independent functions provided in the API.
Linux, the ying and the yang. Tangrs answer is good; it answers your question. However, there is the linux compat projects. See the backports wiki. Basically, there are libraries that provide shim functionality for newer Linux ABI's which you can use to link your code. The KERNEL_VERSION macro that Eugene notes is inspected in a compat.h, and appropriate compat-2.6.38.h, etc are included where each version has either macros and/or library functions to provide a forward API.
This lets the Linux Wifi group write code for the bleeding edge kernel, while still making it possible to compile on older kernel versions.
I guess this answers the question,
if there are any standard ways to deal with versioning?
The compat library is not a panacea, but at least it is there and under development.
Open source - There are many mutations. They all have a different plan.
Are there any free, GCC-compatible suites for Windows that generate standalone executables without external dependencies?
Here are a few that do not fit the bill, ordered by undesirability, least to most:
MinGW (MSVCRT.DLL)
Cygwin (Cygwin runtime DLLs)
DJGPP (NTVDM.EXE; not present on x64 platforms)
Right now I'm leaning towards (and using, albeit tentatively,) MinGW, as it does seem to be the "cleanest" approach. I still am not thrilled with the MSVCRT.DLL dependency, especially as I can and do have to deal with customers running pre-Win2K. (Windows 2000 was the first edition to ship with MSVCRT.DLL) Distributing MSVCRT with the application is not an option.
P.S.: I am aware that there is an attempt to create an MSVCRT replacement for MinGW, but it is still unstable/beta, and has limited functionality; not something I'd feel comfortable using for production applications.
P.P.S.: Answers to the effect of "MSCVRT is usually there anyway," or "Just package the redist" are not constructive answers. The question specifically asks how to AVOID dependencies, not ensure their presence.
To avoid MSVCRT with MinGW, use the following flags for the linker:
-nostdlib -Wl,--exclude-libs,msvcrt.a -Wl,-eWinMain
Notice that you have to declare a function named WinMain (you can also choose another name for it) which will be your main. You also can't use any of the standard functions like strlen, printf and friends. Instead, you must use the WinAPI equivalents like lstrcmp, wsprintf, etc.
You can see an example of this using SCons at:
https://sourceforge.net/p/nsis/code/6160/tree/NSIS/trunk/SCons/Config/gnu
I've used this for my project that also requires Windows 9x compatibility. This also has the nice side effect of having smaller executables. From your comments above, it seems you're looking for that too. If that's the case, there are even more tricks you can use in the file I linked above.
Microsoft has a table matching CRT functions to WinAPI at the following KB99456:
Win32 Equivalents for C Run-Time Functions (Web Archive)
More information on getting rid of CRT (although for VC, it can still help) at:
http://www.catch22.net/tuts/win32/reducing-executable-size
Following link, I'm wondering if there're some side effects of enabling C++0x in GCC.
According to gcc: "GCC's support for C++0x is experimental".
What I'm afraid of is that for example compiler will generate some code differently or standard library uses some C++0x feature which is broken in gcc.
So if I don't explicitly use any of C++0x features, may it break my existing code?
The C++0x support has been, and is under heavy development. One thing this means is that bugs get fixed quickly, another thing it means is that there might be small bugs present. I say small, because of two reasons:
libstdc++ has not been rewritten from scratch, so all the old elements are just as stable as it was before any of this c++0x was available, if not more stable, because of several years of bug fixes.
There's corner cases in the new/old Standard that haven't yet been ironed out. Are these the runtime quirks you talk about? No. C++0x support has been under development for 4 releases now, don't worry.
Most of the impact from that flag will be felt in the new language features, the library features like move constructors and std::thread (on posix platforms) don't affect code not using them.
Bottom line, experimental is too strict a word in daily production. The standard has changed in the three/four years GCC has been working on support. Old revisions of c++0x will be broken in a newer GCC, but that's a good thing. C++0x is finished as far as the non-paying-for-a-pdf-world is concerned, so no breaking changes should be added. Decide if you want the new stuff or not beforehand, because you won't be able to jsut switch it off once you've gotten used to using it.
Usually, it won't break your source code, but you may include (even without noticing it or knowing it) C++0x idioms that will compile because of these features enabled, but won't compile in a strict C++ compiler (for instance, in C++0x you can use >> as a template of template terminator, but not in C++, so if you forget to separate it by a space, you will have problems when you try to compile this code in a C++ compiler).
R-Value references/moves is a feature which can have a huge impact on how the compiler does optimizations and such. Even if you don't use move in your own code, the STD includes will automatically switch to their new versions which include move ctors/assignment.
There are some circumstances which allow the compiler to create move constructors/assignment operators implicitly for user defined classes. These rules changed a few times during the standardization process (I don't even know what the current rules are). So, depending on the exact version of your compiler it could be using a set of rules for generating these implicit functions that isn't even in the latest version of the standard.
Most of the other major C++0x changes don't have big run-time impact, they are mostly compile time (constexpr, string literals, varadic templates) or syntax helpers (foreach, auto, initializer lists).
I originally wrote the question you link because of (in my opinion) a very big issue as described here. Basically, overloading a function with shared_ptr to a const type was not recognized by the compiler. That's a huge flaw in my opinion. It's been fixed from GCC 4.5 to GCC 4.6, but it serves as an example of a big bug that's still around in the default installation of GCC in ubuntu, for example. So while bugs are fixed quickly, there still might be bugs, and you may waste a weekend looking for the source and solution of those bugs.
My recommendation, based on this personal experience, is to avoid C++0x until the word "experimental" is removed from the description of GCC's support of C++0x or until you actually need any of the C++0x features to a degree that an alternative implementation would significantly sacrifice good design.