libpthread в mingw не находит библиотеки - PullRequest
Новая
       10

libpthread в mingw не находит библиотеки

3 голосов
/ 26 июня 2011

Я пытаюсь скомпилировать следующую программу с помощью mingw: 

#include <pthread.h>
#include <errno.h>
#include <unistd.h>
#include <iostream>
#include <cstdio>

void *hello(void *id) {
  int nid = *static_cast<int*>(id);
  std::printf("Hello from thread %d\n", nid);
  return 0;
}

int main(int argc, char **argv) {
  pthread_t ids[2];
  int *params[2];
  for (int i = 0; i < 2; ++i) {
    params[i] = new int;
    *params[i] = i;
    pthread_create(&ids[i], 0, hello, params[i]);
  }
  for (int i = 0; i < 2; ++i)
    pthread_join(ids[i], 0);
  for (int i = 0; i < 2; ++i)
    delete params[i];
  return 0;
}

с помощью этой команды: 

g++ -lpthread -ohello.exe hello.cc

И я получаю следующее сообщение: 

C:\Users\XXXXXX~1\AppData\Local\Temp\cczPlv0w.o:hello.cc:(.text+0xad): undefined 
reference to `_imp__pthread_create'
C:\Users\XXXXXX~1\AppData\Local\Temp\cczPlv0w.o:hello.cc:(.text+0xe9): undefined 
reference to `_imp__pthread_join'
collect2: ld returned 1 exit status

Но с более старой версией MingGW у меня не было проблем с запуском программ pthreads. (Это просто из всех программ, которые потерпели неудачу, но в основном все, что использует pthreads, заканчивается той же ошибкой, C и C ++)

Ответы [ 2 ]

9 голосов
/ 26 июня 2011

Переместить -lpthread в конец этой команды: 

g++ -ohello.exe hello.cc -lpthread

Порядок аргументов важен. (На самом деле рекомендуется использовать -pthread вместо -lpthread для компоновки, поскольку он устанавливает флаги как для препроцессора, так и для компоновщика.)

3 голосов
/ 26 июня 2011

Спецификации библиотеки зависят от позиции с gcc, она будет вводить неразрешенные символы только в той точке, где указана библиотека.

Поскольку в этот момент вы не указали свой основной объектный файл,Единственный неразрешенный символ - main.Вам нужно переместить спецификации библиотеки в точку, где будет неразрешенными символами, которые они могут удовлетворить.

Я никогда не понимал, почему gcc выбрал этот путь, поскольку иногда он приводит кситуации, когда вам нужно перечислить библиотеки более одного раза (например, с циклическими зависимостями).Единственная причина, о которой я когда-либо думал, - это контролировать то, какие библиотеки могут разрешать определенные символы.

Я видел больше «интеллектуальных» компоновщиков, где они просто пакетируют все библиотеки до концазатем просматривайте их снова и снова, пока либо все символы не будут выполнены, либо не будет никакого шанса, что они могут быть.Это экономит много усилий, но вы делаете теряете вышеупомянутый контроль.

...