Adding –emit-relocs option didn’t work neither.Īt last, -shared option saved my life. ld did not generate the base file since it was not supported for 圆4 target (I guess).
#HOW TO USE MINGW W64 DRIVER#
A 64bit driver file is successfully generated but unfortunately Windows 8 圆4 will not load it.Īfter some kernel debug work and research, it seemed the lack of relocation information was the problem. Then compile the driver using 圆4 toolchains (GCC and binutils use many different options: -m64 for gcc, -m i386:x86-64 for dlltool, –64 for as and -m i386pep for ld).
#HOW TO USE MINGW W64 DOWNLOAD#
Now it is time to try making some Windows 圆4 kernel drivers.įirst download MinGW-W64 and install, use the makefile mentioned in my previous post, and disable windows Driver Signature Enforcement.
<< "#unique thread ids: " << ids.size() << '\n' Ĭlang++ -version | grep clang & clang++ -std=c++14 -stdlib=libc++ -O3 -Wall -Wextra -pedantic-errors -pthread main.cpp &./a.outĮcho - & g++ -version | grep GCC & g++ -std=c++14 -g -O0 -Wall -Wextra -pedantic-errors -pthread main.cpp &./a.outĬlang version 3.6.How to compile windows 圆4 driver using MinGW-W64 GCC Std::cout << "hardware concurrency: " << std::thread::hardware_concurrency() << '\n' Std::thread( reverse, "abracadabra" ).detach() // this must be a new thread for( auto& future : futures ) future.get() good implementations would (re)use a thread from the thread pool while( file > str ) futures.push_back( std::async( std::launch::async, reverse, str ) ) Ids.insert( std::this_thread::get_id() ) Std::string reverse( const std::string& str ) #include #include #include #include #include #include #include #include #include namespace The LLVM implementation (libc++) on appears to have implemented a thread-pool layer of its own over the minimalist posix thread model. tasks, you’ll probably get your best performance not by creating a separate thread for each task, but by adjusting the number of threads depending on the amount of parallelism available on your particular system, e.g., the number of cores and their current loads. If you have an algorithm that naturally decomposes into a large number of independent computations, a.k.a. Operating system threads are rather heavy-weight it takes time and system resources to create a thread. The Windows threading model has excellent kernel support (on par with Solaris) for efficient thread pools the Microsoft library implementation of std::async() exploits this (to the extent possible under strict conformance to C++11.) Yes, it is a conforming implementation C++ has nothing to say about how efficiently std::async() should be implemented. As far as possible, avoid the deadly cocktail of g++ / libstdc++ / pthreads which indiscriminately creates threads as if there is no tomorrow. On posix platforms, strongly favour clang++ / libc++. Microsoft had an implementation of the C++11 thread support library even when it was a draft standard.
The C++11 thread support library deliberately specifies very little it was designed to be easily implementable on every commonly found platform for instance the idea of support for thread pools was rejected because posix has no api support for thread pools. There is absolutely nothing in Win32/Win64 threads that makes them incompatible with C++11 threads. Either the Microsoft compiler or the (experimental) LLVM compiler (which too uses the Microsoft library). For any serious concurrent programming using the standard C++11 thread library, strongly favour the Microsoft implementation on Windows.