2010-01-05 15 views
10

Ich habe das folgende Testprogramm.undefined Verweis auf `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; 
} 

Wenn ich es kompilieren, ohne Zugabe der pthread-Bibliothek ich den Fehler für ungelöste Fehler für pthread_mutex_trylock bekommen, aber nur für die Funktion pthread_mutex_trylock.

Wenn ich pthread_mutex_trylock durch pthread_mutex_trlock ersetzen, wird das Programm kompiliert und läuft auch ohne die Option -lpthread *.

Wenn ich hinzufügen, die -lpthraed Option zum Kompilieren alle Läufe gut Befehle diese laufen gut: $ g ++ test2.c -o test2 -lpthread diese warnen ungelöst: $ g ++ test2.c -o test2

Beispiel Fehlerausgang: $ g ++ test2.c -o test2 /tmp/ccU1bBdU.o: In Funktion main': test2.c:(.text+0x11): undefined reference to pthread_mutex_trylock‘ collect2: ld ergab 1 Exit-Status

Wenn ich die ANLEITUNGEN ersetzen auf iret = pthread_mutex_trylock (& mymutex);

mit iret = pthread_mutex_lock (& mymutex); Das Programm kompiliert und läuft ohne Fehler, auch wenn nicht die pthread Bibliothek zum Kompilierbefehl hinzugefügt wurde Ich weiß, dass es richtig ist, den unaufgelösten Fehler zu haben, wenn ich nicht die Option -lpthread verwendet habe, aber warum ich nicht das gleiche habe ungelöster Fehler auch für andere pthread_ Funktion?

Ich bin mit gcc 4.4.2 auf Fedora 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. 

Haben einige haben einen Vorschlag über die Bedeutung dieses Nichtbezugs nur für pthread_mutex_trylock?

Dank für die Hilfe, Enzo

+5

Das könnte ein plattformspezifisches Verhalten sein, aber warum stören Sie das überhaupt? Sie sollen mit Pthread verbinden, tun Sie es einfach. –

+0

mybe Ich habe immer noch den Willen zu lernen :) – enzo2

+1

Trotzdem ist diese Frage in einer Situation wie der meinen nützlich, wo ein Aufruf von 'pthread_mutex_lock()' durch 'pthread_mutex_trylock()' ersetzt wurde, was Dinge aus keinem ersichtlichen Grund verursachte. – foraidt

Antwort

14

Wenn Sie Pthread-Funktionen verwenden, sollten Sie Ihre Objektdateien mit -lpthread verknüpfen und sich nicht darum kümmern, ob Symbole in libc enthalten sind.

Die Begründung dafür ist said zu sein: vor einiger Zeit wurden die Stubs in libc verwendet, wenn Anwendung, die Threads verwendet wurde auf einem System ohne Threading-Unterstützung ausgeführt wurde. Auf einem solchen System wurden pthread_* Funktionen mit libc Stubs verknüpft, die Fehler zurückgaben, die zeigten, dass es keine Threading-Funktionalität gibt. Während auf "threaded" Systeme waren sie mit pthread Bibliothek verknüpft und funktionierte korrekt.

Offensichtlich pthread_mutex_trylock Funktion erschien nach der Richtlinie geändert Verknüpfung mit -lpthread. Also gibt es keinen Stummel dafür.

+0

danke Pavel, jetzt ist dieses seltsame Verhalten ich klar. regars, ebzo – enzo2

+2

BTW, '-lpthread' ist nicht tragbar, und insbesondere ältere Versionen von BSD verwendeten' libc_r', nicht 'libpthread'. Daher ist "-thread" tragbarer und empfohlen. –

14

Sie sollten sowohl die Erstellung und Verknüpfung mit der -pthread Option ausführen, tragbar sein. Auf einigen Systemen werden der Kompilierung spezielle Flags hinzugefügt (z. B. -D_REENTRANT) mit -pthread angegeben.

Wenn Sie wissen möchten, was -pthread mit Ihren Kompilier- und Link-Flags macht, führen Sie gcc -dumpspecs aus.