Unfortunately, the MinGW-w64 installer you used sometimes has this issue. I myself am not sure about why this happens (I think it has something to do with Sourceforge URL redirection or whatever that the installer currently can’t handle properly enough). Anyways, if you’re already planning on using MSYS2, there’s no need for that installer. Download … Read more
Yes, that is correct. However there would have been a simpler, yet identical way; your steps until the bjam call are automatically done by bootstrap.bat: C:\boost_1_52_0> bootstrap.bat mingw Building Boost.Build engine … C:\boost_1_52_0> b2 toolset=gcc If not explicitly specified, the libraries will be placed into the stage\lib directory, include path is the installation root. To … Read more
The solution is to add the option -Wa,-mbig-obj if your version of GCC supports that option. You probably only need it during the compilation step, not the linker step. If your compiler does not support that option, you should look into using mingw-w64 and MSYS2.
Regarding building a DLL using MinGW, here are some very brief instructions. First, you need to mark your functions for export, so they can be used by callers of the DLL. To do this, modify them so they look like (for example) __declspec( dllexport ) int add2(int num){ return num + 2; } then, assuming … Read more
I happened to be looking at the same problem. GCC works fine with std::mutex under Linux. However, on Windows things seem to be worse. In the <mutex> header file shipped with MinGW GCC 4.7.2 (I believe you are using a MinGW GCC version too), I have found that the mutex class is defined under the … Read more
Your commands are wrong ! Go to the directory where your main.cpp file is, and try the following. g++.exe -Wall -c -g main.cpp -o obj\Debug\main.o g++.exe -static -static-libgcc -static-libstdc++ -o “bin\Debug\Hello World.exe” obj\Debug\main.o then you’ll no longer need to copy the DLLs (for your Hello World program). Other notes: The MinGW installation instructions recommends setting … Read more
I also recently updated MinGW and ran into very very similar problems. After some research I found this question on SO and tried replacing -std=c++11 with -std=gnu++11. This resolved the issue for me. Hope that helps!
I made the following changes and it worked for me with the following configurations. OS : Win 7 Prof. SP1 64 bit CPython 3.6 , 64 Bit Mingw 64 (x86_64-7.1.0-posix-seh-rt_v5-rev0) Cython 0.25.2 I did the following Add mingw in the PATH variable (C:\mingw-w64\x86_64-7.1.0-posix-seh-rt_v5-rev0\mingw64\bin for me) Test by opening command line and command gcc works ( … Read more
Put the -lws2_32 AFTER the list of object files – GCC searches libraries and object files in the order they appear on the command line. Just to help the other viewers out there: gcc hello.c -o hello.o -lws2_32
There is a way to suppress the path translation by setting MSYS_NO_PATHCONV=1 in Windows Git MSys or MSYS2_ARG_CONV_EXCL=”*” in MSYS2. Alternatively, you can set the variable only temporarily just for that command by putting the assignment just before the command itself: MSYS_NO_PATHCONV=1 arm-none-linux-gnueabi-gcc.exe -Wall -g \ -Wl,–dynamic-linker=/usr/lib/myrpath/ld-linux.so.3 \ -Wl,-rpath=/usr/lib/myrpath \ -I../targetsysroot/usr/include \ myprogram.c -o myprogram