Compiling Multithread Code with G++ (-Wl,-No-As-Needed Not Working)

Compiling multithread code with g++

The answer was provided by a kind member of SO C++ chat.

It looks like this behaviour is caused by a bug in gcc.

The workaround provided in the last comment of that bug discussion does work and solves the issue:

-Wl,--no-as-needed

Compiling multithread code with Code::Blocks GNU compiler

Your first problem is that -lpthread is a linker option, so it belongs on the linker line (the second command) rather than the compilation line. (Note that the order of the parameters can matter; I got it to work by putting -lpthread on last. I also tried using -pthread instead of -lpthread, which did appear to work and was also less sensitive to where it was put on the linker line. But again, it's a linker option, not a compile option.)

After fixing that, I was able to get your program to compile and run, but it exited with a different exception: terminate called without an active exception. To fix this problem, call thread_fct.join(); in main(). (All threads must be joined, detached, or moved-from before they go out of scope, or your program will abort.)

C++11 link issue with pthread

the answer for similar question "Compiling multithread code with g++ (-Wl,--no-as-needed NOT working)"

is

-pthread is a flag for the compiler, not the linker, the right one for the linker is -lpthread

Using C++11 multithreading in shared library loaded by program without thread support

In thread.cc you can read that this exception is generated if __gthread_active_p returns false. That call simply checks whether or not a given symbol is available. The symbol in question is a weak symbol: it does not have to be present, but its presence is checked to decide whether or not threading is supported.

But what does presence of a symbol mean? In this case it means that the symbol is in the list of symbol tables which the library in question (libgcc_s.so.1 in my case) searches for symbol definitions. That includes symbols exported by the application itself, but also symbols exported by all the libraries loaded before it. However, it does not include libraries loaded afterwards. Unfortunately, if libgcc is loaded before libpthread, then the symbol is not available on its search domain. So it reports threading as unsupported. I guess you have some other C++ module loaded before the multi-threaded one, so you encounter this problem.

One solution which works in my reproducing example is setting LD_PRELOAD=/lib64/libpthread.so.0 in the environment used to call the binary. That loads libpthread up front, so its symbols are available to satisfy the weak symbol linkage. This won't work for setuid/setgid binaries, and might be considered an ugly hack in other cases as well, so I'm interested in cleaner solutions. Nevertheless, this gets the job done most of the time.

Link Time Optimization conflicting with multithreading support

Try to add this parameters:

-Wl,--no-as-needed

If it helps then it's a gcc bug: https://stackoverflow.com/a/19463892/280758

thread with code::blocks error at runtime

If you compile with -pthread you should link with -lpthread.

The second is easy, it must be:-Wl,--no-as-needed (',' is missing), but it is used for the linker. Your call only compiles into an object file, so you can erase that.

Another note on the second one, it might be that you actually have to link with -Wl,--no-as-needed due to a bug in some gcc version

As for Code::Blocks, you can add -Wl,--no-as-needed and -lpthread in the linker tab of the build options.

---

Related Topics