2010-01-05 28 views
10

Tengo el siguiente programa de prueba.referencia indefinida a `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; 
} 

Si puedo compilar sin la adición de la biblioteca pthread consigo el error para el error sin solución por pthread_mutex_trylock, pero sólo para pthread_mutex_trylock función.

Si reemplazo pthread_mutex_trylock con pthread_mutex_trylock, el programa se compila y ejecuta bien también sin la opción -lpthread *.

Si agrego la opción -lpthraed a la compilación manda a todos los funcionamientos así esta carrera así: $ g ++ test2.c -o test2 -lpthread esta advierten sin resolver: $ g ++ test2.c -o test2

salida de error

Ejemplo: $ g ++ test2.c -o test2 /tmp/ccU1bBdU.o: En función main': test2.c:(.text+0x11): undefined reference to pthread_mutex_trylock' collect2: ld volvió 1 estado de salida

Si sustituyo el instructi en iret = pthread_mutex_trylock (& mymutex);

con iret = pthread_mutex_lock (& mymutex); el programa se compila y se ejecuta sin error también si no se agregó pthread libarry al comando de compilación Sé que es correcto tener el error sin resolver si no usé la opción -lpthread, pero por qué no tengo el mismo error no resuelto también para otra función pthread_?

estoy usando gcc 4.4.2 en 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. 

hacer algunos tienen alguna sugerencia sobre el significado de esta Deshacer referencia sólo para pthread_mutex_trylock?

gracias por la ayuda, Enzo

+5

Eso podría ser un comportamiento específico de la plataforma, pero ¿por qué te molestas? Se supone que debes enlazar con pthread, solo hazlo. –

+0

mybe Todavía tengo ganas de aprender :) – enzo2

+1

Sin embargo, esta pregunta es útil en una situación como la mía, donde una llamada a 'pthread_mutex_lock()' fue reemplazada por 'pthread_mutex_trylock()' causando que las cosas se rompan sin ninguna razón obvia. – foraidt

Respuesta

14

Si utiliza funciones pthread debe vincular los archivos de objeto con -lpthread y no preocuparse por si los símbolos están incluidos en libc.

La razón detrás de esto es said para que sea así: hace algún tiempo, los stubs en libc se usaban cuando la aplicación que utilizaba hilos se ejecutaba en un sistema sin enganchar el soporte. En dicho sistema, las funciones pthread_* se vincularon a los resguardos libc que arrojaban errores que mostraban que no hay funcionalidad de subprocesamiento. Mientras estaban en sistemas "enhebrados", se vincularon a la biblioteca pthread y funcionaron correctamente.

Obviamente, la función pthread_mutex_trylock apareció después de cambiar la política a vincular con -lpthread. Entonces no hay un trozo para eso.

+0

gracias Pavel, ahora este extraño comportamiento me aclaro. regars, ebzo – enzo2

+2

BTW, '-lpthread' no es portátil, y en particular, las versiones anteriores de BSD usaban' libc_r', no 'libpthread'. Por lo tanto, '-pthread' es más portátil y recomendado. –

14

Debe realizar tanto la compilación y vinculación con la opción -pthread, para ser portátil. En algunos sistemas, la compilación tendrá indicadores específicos agregados (por ejemplo, -D_REENTRANT) con -pthread especificado.

Si tiene curiosidad por ver qué hará -pthread en sus indicadores de compilación y enlace, ejecute gcc -dumpspecs.