So I decided to give c++ a try today. I downloaded MinGw and the g++ compiler that comes with it. I decided to test the following code:
#include <iostream>
#include <thread>
int foo()
{
std::cout << "foo" << std::endl;
}
int main()
{
std::thread t1(foo);
t1.join();
std::cout << "done" << std::endl;
return 0;
}
I then tried to compile it on the command line using the following line:
g++ -std=c++11 main.cpp
Which works for hello world. This time however, it gave me this error:
error: 'thread' is not a member of 'std'
I tried the exact same code using the g++ provided by cygwin, and it works. So why doesn't it work in MinGw? Is it outdated or something? I want to compile stuff using c++11 and c++14 like on the cygwin terminal, but outside of the cygwin environment.
MinGW-w64 (or rather GCC on windows) needs to be compiled with posix thread support if you want to use std::thread, presumably you downloaded a build with native windows threads.
Check out the mingw-builds folders targeting 64 bit or 32 bit and pick a version with posix threads. You'll also need to choose the exception handling method, if you don't have a reason to choose otherwise then stick with the GCC defaults of seh for 64 bit and dwarf for 32.
I tested this in linux (cross-compiling).
This compiles ok,
i686-w64-mingw32-g++-posix -std=c++11 threads.cpp -lwinpthread
this does not
i686-w64-mingw32-g++-win32 -std=c++11 threads.cpp -lwinpthread
The difference between the compilers is --enable-threads=win32 vs. --enable-threads=posix option used when the compilers were built. g++ -v should show what was used.
Related
I am trying to compile this little program in file demo.cpp by gcc demo.cpp,
#include <iostream>
using namespace std;
int main() {
cout << "Hello World!";
return 0;
}
It does not do so successfully. I get Undefined symbols for architecture arm64:,
This seems like pretty popular error but people are getting it on way more complicated programs. Note that it works if I comment the cout line. I am not sure exactly what am I doing wrong here. gcc -v returns,
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
This is probably because the GCC compiler, according to my experience, is supposed to compile C language codes only, not C++. G++ is used to compile C++. The specific problem with the cout line is that C uses printf(), not cout, to print to the terminal. Therefore, the C compiler outputs your line as undefined symbols.
I'm just trying to understand a concept used by g++. Here my very simple std::thread application:
#include <iostream>
#include <thread>
void func() {
std::cout << "Running..." << std::endl;
}
int main()
{
std::thread t(func);
t.join();
return 0;
}
I'm able to compile it on macOs/Xcode 9.0 setup with following command:
g++ main.cpp -std=c++11
But I'm unable to compile it on Linux with the same command, as far as I know I have to pass -pthread option too. Otherwise it gives me following error:
gcc version 7.1.1 20170622 (Red Hat 7.1.1-3)
main.o: In function `std::thread::thread<void (&)()>(void (&)())':
/usr/include/c++/5/thread:137: undefined reference to `pthread_create'
I think it's illogical and I shouldn't even know that it's implementing the std::thread class via pthread. Why do I have to pass -pthread option and link against pthread library? Isn't C++11 supposed to abstract me away from platform specific details? Or do I have any other alternative libraries such as pthread that I can link against for my std::thread usage? Or should I report that as a bug?
Thanks.
According to GCC's concurrency page, it's necessary to provide additional options to the compiler based on the features being used. You can verify that your version of GCC's threads rely on POSIX threads:
$ gcc -v 2>&1 | grep "Thread model"
Thread model: posix
See this bug report for a justification for the behavior:
The problem is that not all targets need -pthread, or some which do need it spell it differently, and not all platforms define _REENTRANT when the option is used, so there's no reliable way to do what you're asking for.
I am moving pthread to std:thread in C++11 and have encountered the same phenomenon you've been met, and I found this artical -- it may be the proper answer: https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread#
A quick conclusion: It depends on the version of glibc. glibc with versions prior to 2.34 will require the -lpthead flag even the code does not use pthread explicitly.
To check the version of glibc we can use ldd --version command, on my Ubuntu 20.04, it returns like this: ldd (Ubuntu GLIBC 2.31-0ubuntu9.9) 2.31, so I still have to add the -lpthread flag to use std:thread.
pthread is an industry standard over the OS specific threads, using the OS specific calls.
std::thread is an abstraction in C++ that could be implemented using pthread or the OS's native threads. But to make it work on as many OS's as possible fast the std-library implementer could just implement it in posix as they should be good to go on all compliant OS's.
There are exceptions, some windows only std-library uses windows native threads instead.
When using the #if windows/#if linux compilers features in Debian GCC version 4.7.2, I have been unable to get them work when using std11.
Independently, I can get the compiler to accept the if-defines without complaint. I can also get the compiler to use the same code with c++ 11, without any if-defines (and thus not conditionally). But when I run the conditional defines through the same compiler, with the tag for c++ 11, the code is rejected.
Below I have included a simple example, with two alternate mains, and the error I get. The only difference between the two mains are the commented out lines.
Runs:
g++ main.cpp -std=c++11 -o test
The above uses the c++ 11 standard. When running commented main it works perfectly. But when running uncommented main, it fails entirely, giving the error at the far end of this post.
g++ main.cpp -o test
The above does not use the c++ 11 standard. When running either commented main or uncommented main it works perfectly.
Below are the code examples.
Commented main.cpp:
#include <iostream>
//#if windows
//#include "WindowsSolution.hpp"
//#endif
//#if linux
#include "LinuxSolution.hpp"
//#endif
int main()
{
std::cout << myGlobalSolution.out() << std::endl;
return 0;
}
LinuxSolution.hpp:
class LinSolution{
public:
LinSolution(){
}
std::string out(){
std::string ret("Linux solution");
return ret;
}
};
LinSolution myGlobalSolution;
WindowsSolution.hpp:
class WinSolution{
private:
WinSolution(){
}
std::string out(){
std::string ret("Windows solution");
return ret;
}
};
WinSolution myGlobalSolution;
Uncommented main.cpp:
#include <iostream>
#if windows
#include "WindowsSolution.hpp"
#endif
#if linux
#include "LinuxSolution.hpp"
#endif
int main()
{
std::cout << myGlobalSolution.out() << std::endl;
return 0;
}
Below is the error I get when compiling with the uncommented main.cpp, using the c++ 11 flag.
main.cpp: In function ‘int main()’:
main.cpp:13:15: error: ‘myGlobalSolution’ was not declared in this scope
The simple constant linux is a GCC extension and not an official OS constant. The proper constant for Debian is probably __gnu_linux__; you can find a list of them for various systems here. Usually official predefined constants follow the convention of using __ at the start.
Your code works without the standard flag because by default GCC compiles in a GNU language mode (GNU C++) rather than a standard language mode (ISO C++); the GNU language includes extensions (extra language features, and in this case, legacy OS constants). When you pass the -std=c++11 flag you are requesting ISO language mode, which means GNU extensions are disabled, including GNU-only constants. To get both GNU extensions and a specific set of ISO features, try requesting a GNU language standard version instead (e.g. -std=gnu++11 works fine).
--EDIT
If you would like to use MinGW GCC 8.4.1 and threads/mutex/futures/atomics do not download the Win32 threader version insted download the Posix version.
--EDIT
My installation of MinGW is as follows:
x32-4.8.1-release-win32 (as the threader) - sjlj rev 5
I have unpacked and correctly confirmed that MinGW GCC 4.8.1 (revision 5) is installed in C:\MinGW\mingw32. I have set up Code Blocks to look for the latest and greatest compiler in the correct path (this I am sure of). I can compile a normal program using #include iostream. Ok now when I try and run a program using #include thread it gives me "error: 'thread' is not a member of 'std'".
Now here is what I have done and what I have tried:
I am following a sort of template or tutorial here at cplusplus.com.
I have the code exactly as it is presented on the webpage (towards the bottom).
I have tried, in Code Blocks, to use Compiler flags "Have g++ follow the C++11 ISO language standard -std=c++11".
I have also tried the flag "Have g++ follow the coming C++0x ISO language standard -std=c++0x"
I have tried both at the same time and one at a time, no mas.
I have also tried those commands manually.
Another command I tried manually was -std=gnu++11 which was recommended in the thread header.
--EDIT
It seems like __cplusplus is < 201103L which is stated (or rather defined) in the thread header.
This only happens when I manually use -std=c++11, for some reason C::B removes it if it was manually stated so I must use a check box to use this flag...
--EDIT
My compiler settings under the Toolchain Executables tab are as follows:
C compiler: i686-w64-mingw32-gcc-4.8.1.exe
C++ compiler: i686-w64-mingw32-c++.exe
Linker for dynamic: i686-w64-mingw32-c++.exe
Linker for static: ar.exe
Debbuger: GDB/CDB debugger: default
Resource compiler: windres.exe
Make Program: mingw32-make.exe
I have tried using other executables in the bin folder and still no luck...
I'm starting to wonder if GCC supports C++11 or threading !?
Has anyone been able to get threads to work with MinGW GCC, Code blocks or in general?
If so how did you do it? Any links that might help? Any advice?
P.S. I know there are other ways of threading like posix or other SDK's like SFML (I have successfully tried threading with this). But I want to use GCC threading and I'm quite baffled as to why it is so hard to do seeing as all the necessary files are there...
--EDIT
I have found that when I manually compile the program outside of Code Blocks I still get the same errors, whether I use g++ c++ or i686-w64-mingw32-g++/c++
here is the command I run to build the files:
C:\MinGW\mingw32\bin>g++.exe -D__GXX_EXPERIMENTAL_CXX0X__ -o0 -g3
-Wall -c -fmes sage-length=0 -std=c++11 -Wc++11-compat -o obj\Debug\main.o "F:\C Projects\Code Blocks\thread\main.cpp"
still returns error: 'thread' is not a member of 'std'
Could this be a bad build? I will try other revisions...
--EDIT
probably to late for an answere, but here is what worked for me:
1. Get x86_64-w64-mingw32-gcc-4.8-stdthread-win64_rubenvb.7z from:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-experimental-stdthread/
2. Setup a new compiler in codeblocks with
x86_64-w64-mingw32-gcc-4.8.1.exe
x86_64-w64-mingw32-g++.exe
x86_64-w64-mingw32-g++.exe
ar.exe
windres.exe
mingw32-make.exe
3. Set the new compiler for your project
Right click in your project -> build options
Select the new compiler
Under compiler falgs check -std=c++0x and -std=c++11
Under Other options set -std=gnu++11
4. Have fun with c++11 concurrency
Hope that works for you also, as an alternative you can just use visual studio.
I think you meant GCC 4.8.1 - the answer is yes, it supports a set of C++11 features including partial multi-threading support. Please visit http://gcc.gnu.org/releases.html to see supported set.
gcc 4.8.1 is C++11 feature complete. I cannot speak to the Windows implementation but certainly on Linux and OS X it works as advertised, including all the concurrency functionality. I just #include <thread> and call g++ -std=gnu++11 and it works. Here's a minimal piece of code that compiles just fine:
#include <iostream>
#include <thread>
#include <mutex>
std::mutex mx;
int i;
void thrfunc();
int main(void)
{
i=0;
std::thread thr1(thrfunc),thr2(thrfunc);
thr1.join();
thr2.join();
return 0;
}
void thrfunc()
{
mx.lock();
i++;
std::cout << std::this_thread::get_id() << " i: " << i << std::endl;
mx.unlock();
}
I had the same issues, I installed the lates MinGW-Builds
http://sourceforge.net/projects/mingwbuilds/files/mingw-builds-install/
and set my toolchain executables to:
x86_64-w64-mingw32-gcc-4.8.1.exe
x86_64-w64-mingw32-g++.exe
x86_64-w64-mingw32-g++.exe
ar.exe
windres.exe
mingw32-make.exe
I hope this helps.
I'm writing a simple C++ program to demonstrate the use of locks. I am using codeblocks and gnu gcc compiler.
#include <iostream>
#include <thread>
#include <mutex>
using namespace std;
int x = 0; // shared variable
void synchronized_procedure()
{
static std::mutex m;
m.lock();
x = x + 1;
if (x < 5)
{
cout<<"hello";
}
m.unlock();
}
int main()
{
synchronized_procedure();
x=x+2;
cout<<"x is"<<x;
}
I'm getting the following error: mutex in namespace std does not name a type.
Why am I getting this error?
Doesn't the compiler support use of locks?
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 following #if guard:
#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)
Regretfully, _GLIBCXX_HAS_GTHREADS is not defined on Windows. The runtime support is simply not there.
You may also want to ask questions directly on the MinGW mailing list, in case some GCC gurus may help you out.
EDIT: The MinGW-w64 projects provides the necessary runtime support. Check out http://mingw-w64.sourceforge.net/ and https://sourceforge.net/projects/mingw-w64/files/. Also, as 0xC0000022L pointed out, you need to download the POSIX thread version (I missed mentioning it last time).
Use POSIX threading model for MINGW:
$ sudo update-alternatives --config i686-w64-mingw32-gcc
<choose i686-w64-mingw32-gcc-posix from the list>
$ sudo update-alternatives --config i686-w64-mingw32-g++
<choose i686-w64-mingw32-g++-posix from the list>
$ sudo update-alternatives --config x86_64-w64-mingw32-gcc
<choose x86_64-w64-mingw32-gcc-posix from the list>
$ sudo update-alternatives --config x86_64-w64-mingw32-g++
<choose x86_64-w64-mingw32-g++-posix from the list>
See also: mingw-w64 threads: posix vs win32
This has now been included in MingW (Version 2013072300). To include it you have to select the pthreads package in the MinGW Installation Manager.
Mutex, at least, is not supported in 'Thread model: win32' of the Mingw-builds toolchains. You must select any of the toolchains with 'Thread model: posix'. After trying with several versions and revisions (both architectures i686 and x86_64) I only found support in x86_64-4.9.2-posix-seh-rt_v3-rev1 being the thread model, IMO, the determining factor.
I encountered this same problem when using MingW-W64 7.2.0. I tested out several different Windows builds from the mingw-64 download page, and found that MinGW-W64 GCC-8.1.0 supports mutex and contains the pthread library. When installing, I selected the following options:
x86_64
posix
seh
My multi-threaded code based on pthreads now compiles and runs cleanly on both Windows and Linux with no changes.
This version is leaner than the 7.3.0 build I was using because it doesn't have a CygWin environment or package manager. I also copied mingw32-make.exe to make.exe so my Makefile wouldn't need to be modified. The installer creates a "Run terminal" link in the Windows Start Menu.
I got the same error with gcc4.7.7.
After adding "-std=c++0x", it is fixed.
my gcc version is 5.4 and i solved this problem when adding #include and also adding -std=c++11 at my CmakeLists.txt as below:
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -O3 -march=native -std=c++11")
I fixed it by following steps:
Project > Build option...
The default selected compiler: GNU GCC Compiler
On tab "Compiler settings / Compiler flags", check option
"Have g++ follow the C++11 ISO C++ language standard [-std=c++11]"
I don't know if it works for everybody, but in other way you just have to update your ndk. I'm using ndk-r11c and it works perfectly.
Many classes of the standard thread library can be replaced with the boost ones. A very easy workaround is to change the entire standard mutex file with a couple of lines.
#include <boost/thread.hpp>
namespace std
{
using boost::mutex;
using boost::recursive_mutex;
using boost::lock_guard;
using boost::condition_variable;
using boost::unique_lock;
using boost::thread;
}
And do not forget to link against boost thread library.