2010-01-05 16 views
10

Mam następujący program testowy.niezdefiniowane odniesienie do `pthread_mutex_trylock '

#include <iostream> 
#include <cstdlib> 

using namespace std;  
pthread_mutex_t mymutex = PTHREAD_MUTEX_INITIALIZER; 

int main(int argc, char *argv[]) 
{ 
    int iret; 
    iret = pthread_mutex_trylock(& mymutex); 
    cout << "Test2 !!! " << endl; 
    pthread_mutex_unlock(& mymutex); 
    return EXIT_SUCCESS; 
} 

Gdybym go skompilować bez dodawania biblioteki pthread pojawia się błąd na nierozwiązany problem dla pthread_mutex_trylock, ale tylko dla funkcji pthread_mutex_trylock.

Jeśli zamieniam pthread_mutex_trylock na pthread_mutex_trylock, program zostanie skompilowany i będzie działał dobrze również bez opcji -lpthread *.

jeśli dodać -lpthraed opcja do kompilacji polecenia wszystkie działa dobrze to działa dobrze: $ g ++ -o test2.c test2 -lpthread to ostrzec nierozwiązany: $ g ++ -o test2.c test2

wyjście błędów

Przykład: $ g ++ -o test2.c test2 /tmp/ccU1bBdU.o: funkcja main': test2.c:(.text+0x11): undefined reference to pthread_mutex_trylock” collect2: ld zwróconym stanem wyjścia 1

Gdybym wymienić instructi na iret = pthread_mutex_trylock (& mymutex);

z iret = pthread_mutex_lock (& mymutex); program kompiluje się i działa bez błędu również, jeśli nie dodałem biblioteki pthread do komendy kompilacji Wiem, że to dobrze, że nierozwiązany błąd, gdybym nie użył opcji -lpthread, ale dlaczego nie mam tego samego nierozwiązany błąd również dla innej funkcji pthread_?

Używam gcc 4.4.2 w Fedorze 12

$ g++ --version 
g++ (GCC) 4.4.2 20091222 (Red Hat 4.4.2-20) 
Copyright (C) 2009 Free Software Foundation, Inc. 
This is free software; see the source for copying conditions. There is NO 
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 

Czy niektóre mają jakieś sugestie na temat znaczenia tego unreference tylko dla pthread_mutex_trylock?

dzięki za pomoc, Enzo

+5

To może być jakaś platforma zachowanie specyficznych, ale dlaczego nawet przeszkadza? Powinieneś połączyć się z pthread, po prostu to zrób. –

+0

mybe mam nadal woli, aby dowiedzieć się :) – enzo2

+1

Niemniej kwestia ta jest przydatna w sytuacji takiej jak moja, gdzie wywołanie 'pthread_mutex_lock()' 'została zastąpiona przez pthread_mutex_trylock()' powodujące rzeczy złamać bez wyraźnego powodu. – foraidt

Odpowiedz

14

Jeśli używasz funkcji pthread, powiąż pliki obiektów z -lpthread i nie martw się, czy symbole są zawarte w libc.

Powodem tego jest said być takim: jakiś czas temu kody pośredniczące w bibliotece libc zostały użyte, gdy aplikacja używająca wątków była uruchamiana w systemie bez obsługi wątków. W takim systemie funkcje pthread_* zostały połączone z kodami libc, które zwróciły błędy pokazujące, że nie ma funkcji wątków. W systemach "gwintowych" były one połączone z biblioteką pthread i działały poprawnie.

Oczywiście funkcja pthread_mutex_trylock pojawiła się po zmianie zasady na połączenie z -lpthread. Więc nie ma w tym nic dziwnego.

+0

podziękować Pavel, teraz to dziwne zachowanie i Smore jasne. regars, ebzo – enzo2

+2

BTW, '-lpthread' nie jest przenośny, aw szczególności starsze wersje BSD wykorzystywane' libc_r', nie 'libpthread'. Dlatego '-pthread' jest bardziej przenośny i zalecany. –

14

Należy wykonać zarówno kompilację i powiązania z opcją -pthread, być przenośne. W niektórych systemach kompilacja będzie zawierać określone znaczniki (np. -D_REENTRANT) z określoną wartością -pthread.

Jeśli chcesz zobaczyć, co zrobi -pthread z flagami kompilacji i linków, uruchom gcc -dumpspecs.

Powiązane problemy