Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: NanoGoner on December 23, 2012, 08:55:08 pm

Title: Linking the pthread library
Post by: NanoGoner on December 23, 2012, 08:55:08 pm
I am running ubuntu Linux and am developing a program in C++.  In the program I am trying to start a thread with the following code:
-----------------------------------------------------------------------------

#include <pthread.h>
void *updater (unsigned char matrix[8][8]);

int main (int argc, char **argv)
{
   pthread_t mat_thread
   int iret, i, x;
   iret = pthread_create(&mat_thread, NULL, updater, matrix);
....

------------------------------------------------------

When I build the program files I get 1 error which is:


undefined reference to 'pthread_create'


I have installed g++ and gdb and at first I presumed this meant the pthread library file (libpthread.so) was not available.
I am told on another C++ forum that I need the following linking command to link the library into the build:

g++ *.cpp -pthread

This is a command line operation.
Can some one tell me how I accomplish this within CodeBlocks.  I'm brand new to it.
Title: Re: Linking the pthread library
Post by: Jenna on December 23, 2012, 09:17:09 pm
You can add any commandline option to to your projects build options ("{Compiler|Linker} settings -> Other [linker ]options").

The Code::Blocks manual (http://www.codeblocks.org/user-manual) and our wiki (http://wiki.codeblocks.org/index.php?title=Main_Page) might also be helpful to see what is possible.
Title: Re: Linking the pthread library
Post by: renebarto on January 16, 2014, 11:25:27 pm
Dear Jens, I see the same problem, and the documentation is not helping me. When I use the cbp2make tool to create a makefile, the compilation and linkage work perfectly. When building from within cb, the linker fails.  ??? The command it spits out is exacly the same, but for some reason the compiler does not try to link the libraries, resulting in undefined references.
What could be wrong?
Title: Re: Linking the pthread library
Post by: renebarto on January 16, 2014, 11:28:36 pm
Just for information this is part of the build log:

g++ -L../../../bin/Debug  -o ../../../bin/Debug/Core.Test obj/Debug/external/gtest/gtest-all.o .... obj/Debug/src/Main.o   -Wl,-rpath,'$ORIGIN'  -lCore -lpthread -lrt
obj/Debug/external/gtest/gtest-all.o: In function `~ThreadLocal':
/home/developer/workspace/source/product/components/Core.Test/external/gtest/gtest.h:2589: undefined reference to `pthread_getspecific'

The only difference I can see is that cb internally jams in spaces into the command line.
Title: Re: Linking the pthread library
Post by: BlueHazzard on January 16, 2014, 11:43:32 pm
http://wiki.codeblocks.org/index.php?title=FAQ-Compiling_%28general%29#Q:_How_do_I_report_a_compilation_problem_on_the_forums.3F
Title: Re: Linking the pthread library
Post by: BlueHazzard on January 16, 2014, 11:45:36 pm
don't enter pthread under libraries, but in additional linker options as -pthread
Title: Re: Linking the pthread library
Post by: renebarto on January 16, 2014, 11:45:55 pm
One more post, as I think I've figured out what is going wrong: The command buffer is too small. Only part of the command line is sent to sh. I've added an echo to the linker command, and it leaves out part of the command line. I am currently trying out cb 10.05, on Ubuntu 12.04 with gcc.

-------------- Build: Debug in Core.Test ---------------

echo g++ -L../../../bin/Debug  -o ../../../bin/Debug/Core.Test obj/Debug/external/gtest/gtest-all.o obj/Debug/src/CoreActiveObjectTest.o obj/Debug/src/CoreArrayTest.o obj/Debug/src/CoreAutoEventTest.o obj/Debug/src/CoreByteArrayTest.o obj/Debug/src/CoreCyclicBufferTest.o obj/Debug/src/CoreManualEventTest.o obj/Debug/src/CoreMutexTest.o obj/Debug/src/CoreStreamTest.o obj/Debug/src/CoreTextReaderTest.o obj/Debug/src/CoreTextWriterTest.o obj/Debug/src/CoreThreadTest.o obj/Debug/src/CoreTimeStampTest.o obj/Debug/src/CoreTimerTest.o obj/Debug/src/CoreWorkerThreadTest.o obj/Debug/src/Main.o   -Wl,-rpath,'$ORIGIN'  -lCore -lpthread -lrt
g++ -L../../../bin/Debug -o ../../../bin/Debug/Core.Test obj/Debug/external/gtest/gtest-all.o obj/Debug/src/CoreActiveObjectTest.o obj/Debug/src/CoreArrayTest.o obj/Debug/src/CoreAutoEventTest.o obj/Debug/src/CoreByteArrayTest.o obj/Debug/src/CoreCyclicBufferTest.o obj/Debug/src/CoreManualEventTest.o obj/Debug/src/CoreMutexTest.o obj/Debug/src/CoreStreamTest.o obj/Debug/src/CoreTextReaderTest.o obj/Debug/src/CoreTextWriterTest.o obj/Debug/src/CoreThreadTest.o obj/Debug/src/CoreTimeStampTest.o obj/Debug/src/CoreTimerTest.o obj/Debug/src/CoreWorkerThreadTest.o obj/Debug/src/Main.o -Wl,-rpath,
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings
 
Title: Re: Linking the pthread library
Post by: BlueHazzard on January 16, 2014, 11:51:10 pm
look at my previous post.

(c::b 10.05 is really old, don't expect many support for this old version, it has changed a lot since them)
please post logs/code in code tags...

greetings
Title: Re: Linking the pthread library
Post by: renebarto on January 17, 2014, 12:04:52 am
Thx I was not aware of that. I will download the current version for Ubuntu.
Title: Re: Linking the pthread library
Post by: mloutris on January 16, 2018, 04:38:30 am
don't enter pthread under libraries, but in additional linker options as -pthread

I ran into this as well. To be more precise, in CB 16.01, from the top menu bar, select 'Settings->Compiler'
Then select the 'Linker Settings' tab, and near the bottom of the window, select the 'Add' button,
enter 'pthread' (without the single quotes!), as Code::Blocks will prepend the '-l' automatically.
Click on the 'OK' button and rebuild.
Title: Re: Linking the pthread library
Post by: oBFusCATed on January 16, 2018, 07:31:25 am
mloutris: This solution is wrong on many levels.

1. You need to pass -pthread not -lpthread.
2. You need to pass it both to the compiler and linker.
3. Putting such options in the global settings is wrong, you need to put these in the project, so the code could be moved from one machine to the next...

The original problem in the topic is related to the use of rpath=@ORIGIN by the looks of it...