C++ multithreading errors - c++

I have been starting to try and learn how to utilize multithreading in c++, but the #include<thread> causes issues with the thread type being not declared in the scope. error: 'thread' was not declared in this scope. I have been doing research, and I have come across a lot of answers regarding how to solve this issue. Im presently at the understanding that my compiler, MinGW, doesn't support thread effectively, but I am not sure what to do with that information.
Any guidance on this matter is appreciated.
Also, I think this may be helpful. If I run gcc -v on my command line, I get this output:
Using built-in specs.
COLLECT_GCC=c:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --target=mingw32 --with-gmp=/mingw --with-mpfr --with-mpc=/mingw --with-isl=/mingw --prefix=/mingw --disable-win32-registry --with-arch=i586 --with-tune=generic --enable-languages=c,c++,objc,obj-c++,fortran,ada --with-pkgversion='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared --enable-threads --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw --enable-libstdcxx-debug --enable-libgomp --disable-libvtv --enable-nls
Thread model: win32
gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)
edit: I've seen this webpage, https://github.com/meganz/mingw-std-threads, as a potential solution, but I don't think this works for me. Unless somehow I am putting the mingw-thread.h in the wrong folder.

I think the problem here is you did not tell the compiler using c++11 features. 'thread' is belonged to c++11 features, let try adding -std=c++11 into CXXFLAGS or CPPFLAGS and see if it resolves your problem

My psychic powers suggest your forgot the std:: namespace attribute. That would explain why thread is undefined, even with #include <thread>. The other answer about -std=c++11 is also steering you into the right direction. And don't forget the -pthread compiler/linker option.
$ cat foo.cpp
#include <thread>
#include <iostream>
void threadfunc()
{
std::cout << "Hello from the worker thread" << std::endl;
}
int main()
{
std::thread t(threadfunc);
t.join();
return 0;
}
$ g++ foo.cpp -std=c++11 -o foo -pthread
$ ./foo
Hello from the worker thread

Related

GCC v12.1 warning about serial compilation

I have upgraded my whole arch linux system today (12th May, 2022). gcc was also upgraded from v11.2 to v12.1. I tried compiling some of my programs with g++ (part of gcc compiler collection) by the following command:
g++ -O3 -DNDEBUG -Os -Ofast -Og -s -march=native -flto -funroll-all-loops -std=c++20 main.cc -o ./main
The program compiled perfectly and ran as excepted without any errors, but I got a warning:
lto-wrapper: warning: using serial compilation of 2 LTRANS jobs
But, when the same program was compiled using v11.2 it produces zero number of errors and warnings.
My Questions:
What is the meaning of this warning?
How can I fix this?
Is this warning occurred due to upgrading gcc version to v12.1
Here's the g++ configuration on my machine:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror --with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (GCC)
Apparently that is a recent change in the -flto option. With a little bit of variation in the google search I was able to find this mail conversation:
Likewise if people just use -flto and auto-detection
finds nothing:
warning: using serial compilation of N LTRANS jobs
note: refer to http://.... for how to use parallel compile
[...]
That is, teach users rather than second-guessing and eventually
blowing things up. IMHO only the jobserver mode is safe to
automatically use.
So this is about using the -flto options correctly. I could not manage to easily get a GCC 12 on my system and thus could not try it myself, but you can try -flto=1 or -flto=auto to get rid of the warning.
Anyway it seems that this warning is rather harmless. It just tells you that GCC uses 2 threads in parallel to do the link time optimization.
The exact semantics and effects of the -flto is (together with the other optimization options) described in detail in the GCC manual. By the way you should not spam optimization options like you do in your command line. For example specifying multiple -O... options will only have the effect of the last one of them. Unless you know exactly what you are doing and have carefully read the manual, just stick to use -O3 and you will be fine.

G++ doesn't allow me to define a member function named "major"

So, today I was coding some unit tests, and suddenly G++ gave me an unexpected warning regarding GNU C and one of my member functions named major. Why can't I have a member function named major without triggering G++?
This is a minimally viable test snippet:
// Any of these includes trigger the warnings
#include <random>
#include <cstdlib>
class my_class {
public:
void major() const;
};
inline void my_class::major() const {}
int main(void) {
my_class my_obj;
my_obj.major();
return 0;
}
And this is the output of the compilation (using g++ --std=c++14 -o test-gcc-major test-gcc-major.cpp):
[flisboac#sonic ~]$ uname -a && lsb_release -a && g++ -v && g++ --std=c++14 -o test-gcc-major test-gcc-major.cpp && ./test-gcc-major
Linux sonic 4.12.10-1-ARCH #1 SMP PREEMPT Wed Aug 30 12:18:42 CEST 2017 x86_64 GNU/Linux
LSB Version: 1.4
Distributor ID: Arch
Description: Arch Linux
Release: rolling
Codename: n/a
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc-multilib/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.1.1 20170630 (GCC)
test-gcc-major.cpp:7:13: warning: In the GNU C Library, "major" is defined
by <sys/sysmacros.h>. For historical compatibility, it is
currently defined by <sys/types.h> as well, but we plan to
remove this soon. To use "major", include <sys/sysmacros.h>
directly. If you did not intend to use a system-defined macro
"major", you should undefine it after including <sys/types.h>.
void major() const;
^~~~~~~~
test-gcc-major.cpp:10:13: warning: In the GNU C Library, "major" is defined
by <sys/sysmacros.h>. For historical compatibility, it is
currently defined by <sys/types.h> as well, but we plan to
remove this soon. To use "major", include <sys/sysmacros.h>
directly. If you did not intend to use a system-defined macro
"major", you should undefine it after including <sys/types.h>.
inline void my_class::major() const {}
^~~~~~~~~~~~~~~~~~~~~~~~~~
test-gcc-major.cpp:14:13: warning: In the GNU C Library, "major" is defined
by <sys/sysmacros.h>. For historical compatibility, it is
currently defined by <sys/types.h> as well, but we plan to
remove this soon. To use "major", include <sys/sysmacros.h>
directly. If you did not intend to use a system-defined macro
"major", you should undefine it after including <sys/types.h>.
my_obj.major();
The warning is triggered for every line referencing the member function in any way. Also, I can't undefine anything, because I'm implementing a library, and that burden should fall under the final user.
So, does someone know why this warning is being raised up? I'm not even using C anywhere in my code. All I'm using is <random>, which is not C, per se (but may include a "C" library, who knows?).
In any case, is there any way to detect the need and undefine major at compile-time (e.g. with some pre-processor voodoo)?
UPDATE: I'm using <random>, not <cstdlib>. I just found out that <cstdlib>also triggers the warning.
It is OK to undefine the macro, which is here for backward compatibility only, will soon be removed, and shouldn't have been there in the first place. There is no way this #undef can possibly break or harm user code.
If your users need the macro and your header included in the same source file, let them sort it out themselves. They would have to anyway, whether you include an offending header or not and whether you #undef it or not.
Unfortunately the solution is to stop trying to make a member called major. Otherwise you'll need to #undef major which seems quite unpleasant for a library to do (presumably in a header file).

Can't compile C++ file.cpp. C++98 mode

I'm new to C++. When I write
for (char* c : v)
{
cout << c;
}
I get
"range-based ‘for’ loops are not allowed in C++98 mode"
As far as I understand, I have to change my GCC version (or just mode?). My g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) `
Can't compile from vim (with c.vim plugin), sublime text3 and from terminal using gcc program.cpp and gcc -pedantic -std=c99 program.cpp.
I've downloaded gcc 4.8.1 but It's not deb package so can't install it properly. Also heard about C++11, C++14, C++98, C++99. Where/how can I get/install the latest version?
Solution for vim plugin c.vim:
Edit "c.vim/plugin/c.vim". Change this line
let s:C_CplusCFlags = '-Wall -g -O0 -c -std=c++11' " C++ compiler flags: compile, don't optimize
I've added "-std=c++11" and it works.
The range based for loop is part of C++11, so you will need to use -std=c++11 with G++ to enable the C++11 features.
As mentioned in the previous answer, you are attempting to use a feature of the latest C++ standard (called C++11) while compiling for older standard.
C++11 is the latest C++ standard and the only one supporting range based for.
Now you need to distinguish between the C++ standard and the compiler support for that standard.
Along the past few years, support for C++11 features was gradually added to the gcc compiler.
The following link shows which C++11 feature is supported by which gcc version:
C++0x/C++11 Support in GCC
As you can see, range based for was added in gcc 4.6, so you do not need gcc 4.8 in order to use this feature - gcc 4.6 or later will suffice.
When compiling, you will also need to tell the compiler which standard to compile against. The -std=whatever tells the compiler which standard to use.
You are currently using "-std=c99", telling the compiler to compile using an old C++ standard. Instead you need to set this flag to c++11. If this doesn't work on the gcc version you are using, try using "-std=c++0x" instead (C++0x is an old name of the C++11 standard.)

Crash during program startup when linking against Boost regex library

Our project (in C++) needs to link against boost regex so we just locate the correct compiled libboost_regex_1.45.0 and tell g++ to link against it. Compiling is successful and we just get the right executable as expected. The problem is, each time we try to run the executable, it crashes before entering main() routine.
Attaching the generated core file with gdb, the backtrace command shows there's a segmentation fault during __bultin_strlen, which is resolved to strlen##GLBC_2.2.5.
Since our executable is linked against several dynamic libraries, readelf -s is harnessed to identify the problematic symbol and it boils down to libboost_regex. However the referred symbol is already there in RHEL6 system folder /lib64/libc.so.
The question is, how can we get boost regex working properly?
OS: RHEL6.2
GCC: 4.3.2 / libstdc++6.0.13
Boost libraries is built by exactly the same toolset - user-config.bjam is customized
Static linking is not a good choice for us for various reasons.
The symbol info and ldd info is attached at https://gist.github.com/skyscribe/5184622
From the gdb backtrace, we see that the std::char_traits<char>::length method with argument \"http:\\\\/\\\\/localhostr.com\\\\/files\\\\/.+?\" is triggering the segmentation fault. g++ 4.3.2 introduced new Stack Smashing Protection features, which may interfere with the strlen length computation.
Recompile/relink your code with a recent g++ compiler and see if you solve this error. This sample code does not reproduce such error:
user#workstation ~
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.5.3/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: /gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/configure --srcdir=/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/gcc4 -C --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite --enable-lto --enable-java-awt=gtk --disable-symvers --enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada --enable-threads=posix --with-arch=i686 --with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind --with-ecj-jar=/usr/share/java/ecj.jar
Thread model: posix
gcc version 4.5.3 (GCC)
user#workstation ~
$ cat test.cc
#include <iostream>
#include <string>
int main(int argc, char *argv[]) {
char * a = "\"http:\\\\/\\\\/localhostr.com\\\\/files\\\\/.+?\"";
int t = std::char_traits<char>::length (a);
std::cout << t << std::endl;
}
user#workstation ~
$ g++ -g test.cc
test.cc: In function ‘int main(int, char**)’:
test.cc:6:14: warning: deprecated conversion from string constant to ‘char*’
user#workstation ~
$ gdb a.exe
Reading symbols from /home/user/a.exe...done.
(gdb) b std::char_traits<char>::length
Breakpoint 1 at 0x4017f6: file /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/bits/char_traits.h, line 263.
(gdb) r
Starting program: /home/user/a.exe
[New Thread 764.0x5e4]
[New Thread 764.0x100c]
Breakpoint 1, std::char_traits<char>::length (__s=0x402080 "\"http:\\\\/\\\\/localhostr.com\\\\/files\\\\/.+?\"") at /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/bits/char_traits.h:263
263 { return __builtin_strlen(__s); }
(gdb) c
Continuing.
41
[Inferior 1 (process 764) exited normally]
(gdb)

MinGW won't compile, Error 1

Making a simple hello world app in c++, but it won't compile. I have the folder C:\WiiGames\e3\ with the files main.cpp and Makefile. My makefile is:
build: main.cpp
C:/MinGW/bin/g++.exe main.cpp -o e3.exe
My error is:
C:\WiiGames\e3>make build
C:/MinGW/bin/g++.exe main.cpp -o e3.exe
make: *** [build] Error 1
C:\WiiGames\e3>
Any help would be greatly appreciated.
My code:
#include <iostream>
#include <stdio.h>
#include <string>
#include <cmath>
#include <cstdlib>
#include <time.h>
int main() {
printf("Hello World!");
}
g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.6.2 (GCC)
Make sure it is a tab rather than spaces in the make file before the c:/mingw... Line. It looks like it is make giving the error, not g++.
What happens when you run g++.exe main.cpp -o e3.exe on the command line directly? If nothing happens, is g++ in your path? I'd start by making sure that g++ is setup and in your path.
Yes, it's an old question. These are some solutions i came across (YMMV a lot):
Check if your paths start with c:/ as opposed to /c/ or vice-versa.
Check if you're running in the right shell, i.e., one of:
c:\msys64\msys2_shell.cmd -mingw32
c:\msys64\mingw32.exe
c:\msys64\usr\bin\bash.exe
which may differ if used within an IDE.