Undefined Reference to 'Pthread_Init' When Using -Lpthread Flag:

Undefined Reference to `pthread_init' When Using -lpthread Flag:

Don't call pthread_init(). It's not necessary on Linux.

Linker errors in compiling a simple pthread code under MingW

You need to specify the library on the gcc/g++ command line after the files that depend on the library. So try:

g++ -IC:/MinGW/include/ test.cpp -lpthread

I kicked myself when I stumbled on the answer (it's kind of a FAQ for libraries and gcc). For most gcc options order doesn't matter, but for libraries it's critical.

You should not have to specify the library path if the pthread library came with your MinGW distribution (as it seems is the case for you). Also, remember that the command line above will produce an a.exe executable; pass -o test.exe to avoid that.

Pthreads C++ compilation error

It will depend on your platform, but I would try adding -lpthread to your link command as that's what is required in Linux and a few others. Your program compiles fine here as g++ foo.cc -lpthread.

Troubles with POSIX program using threads with gcc

You could try compiling with the -pthread option, which tells gcc to link against the pthread library.

Undefined reference to C++ libraries

Put the library at the end:

g++ -Wall -pthread test.cpp liboutputdevice.a

Use -pthread instead of -lpthread (see gcc - significance of -pthread flag when compiling).

no reference to pthread_mutex_lock with -lpthread compiled

Order matters, so use:

gcc prodcon.c -lpthread 

Or better:

gcc -Wall -Wextra -pedantic -pthread prodcon.c -lpthread

---

Are you sure you use pthead_mutex_lock? Or is this a typo? Anyways it should be pthread_mutex_lock. Same for pthread_mutex_unlock.

Segmentation Fault in pthreads, Linux Ubuntu

Your vec_length has type int. With gcc on Linux x86 or x86_64, int is represented in 32-bit two's complement format. This is sufficient to accommodate the value you're using for vec_length, 1,000,000,000, but not to accommodate most integer multiples of that value. You compute several such multiples, and the resulting overflow of a signed integer formally produces undefined behavior.

In practice, it is likely that gcc's actual behavior upon signed integer overflow is reproducible. In that case, you can write a program to demonstrate for yourself that the results are negative for several small-integer multiples of your vector length. Where that occurs, your program will attempt to access outside the bounds of each of the two vectors, at the line where indeed the error is indicated, with a segfault being a likely result. (And even if the overflow results were not reproducible, obtaining a negative result for some of those undefined multiplication behaviors would still be well within the realm of possibility.)

You have several alternatives, among them:

• use a wider data type for your indexing computations

  int myStart = myId * (int64_t) vec_length / thread_count;
  

• use only thread_count values that evenly divide the vec_length, and use parentheses to ensure that the division is performed first in your indexing computations

  int myStart = myId * (vec_length / thread_count);
  // ...
  vec_length = 1000000000;
  thread_count = 32;  // or 10 or 8 or 1000
  

---

A few other things:

• The code presented does not use any math.h functions. It therefore does not need to #include math.h, and you do not need to link in libm.
• To compile a Pthreads program with GCC, you ought to use the -pthreads flag, in which case you also do not need to explicitly link in libpthread.
• As discussed in comments, you do not need the complication of a pthread_attr_t.
• As discussed in comments, your particular use of a mutex is an unnecessary performance drain.

---

Related Topics