¿Cuál es la diferencia entre gcc -pthready gcc -lpthreadcuál se usa al compilar programas multiproceso?
Respuestas:
-pthread le dice al compilador que se vincule en la biblioteca pthread y que configure la compilación para subprocesos.
Por ejemplo, a continuación se muestran las macros que se definen cuando la -pthreadopción se usa en el paquete GCC instalado en mi máquina Ubuntu:
$ gcc -pthread -E -dM test.c > dm.pthread.txt
$ gcc -E -dM test.c > dm.nopthread.txt
$ diff dm.pthread.txt dm.nopthread.txt
152d151
< #define _REENTRANT 1
208d206
< #define __USE_REENTRANT 1El uso de la -lpthreadopción solo hace que la biblioteca pthread esté vinculada; las macros predefinidas no se definen.
En pocas palabras: deberías usar la -pthreadopción.
Nota: la -pthreadopción está documentada como una opción específica de la plataforma en los documentos de GCC, por lo que es posible que no siempre esté disponible. Sin embargo, está disponible en plataformas para las que los documentos de GCC no lo enumeran explícitamente (como i386 y x86-64); debe usarlo cuando esté disponible.
También tenga en cuenta que GCC ha utilizado otras opciones similares, como -pthreads(enumeradas como sinónimo de -pthreaden Solaris 2) y -mthread(para compatibilidad con subprocesos específicos de MinGW en Windows i386 y x86-64). Tengo entendido que GCC está tratando de pasar al uso -pthreaduniformemente en el futuro.
-lpthreades suficiente para obtener toda la biblioteca de subprocesos POSIX.
-lpthread hace llegar a toda la librería de hilos POSIX.
-lpthreaddebería ser suficiente para obtener soporte completo para pthreads. No se deberían necesitar otras banderas de compilación.
-lpthreadpero no -pthreades insuficiente para obtener soporte de pthread, como ya aclaré en mi comentario anterior.
-lpthread. Sin embargo, la documentación de gcc sugiere que esto podría ser insuficiente para obtener soporte para pthreads, que es el punto que expuse en los comentarios anteriores. No me importa en absoluto lo que suceda si no proporciona -lpthreado algunas otras opciones patentadas al azar. -lpthreadPOSIX solo lo especifica para garantizar pthreads y eso no parece ser suficiente con gcc.
-pthreadAgrega soporte para subprocesos múltiples con la biblioteca pthreads. Esta opción establece indicadores tanto para el preprocesador como para el enlazador (man gcc ).
mientras
-lpthread entre en existencia mientras se vincula, no habrá influencia durante el preprocesamiento.
Hay una respuesta aceptada, pero, en mi opinión, no proporciona suficiente contexto y conocimiento. De ahí esta respuesta adicional.
-lpthread es una solución para un problema que ya no existe (desde ~ 2005).
En los viejos tiempos, había implementaciones propietarias de la API de Pthreads que no eran compatibles con POSIX, como LinuxThreads . El estándar POSIX simplemente dice que si uno quiere un comportamiento compatible con POSIX, entonces se debe vincular -lpthready vincular eso es necesario para vincular una implementación compatible con POSIX de la API de Pthreads, en caso de que haya muchas implementaciones .
No hay múltiples implementaciones de la API de Pthreads en los sistemas operativos modernos. Y es por eso que -lpthreadya no sirve para nada.
Los compiladores como gccy clang(y, probablemente, todos los compiladores compatibles con Linux) requieren el uso -pthreadde la opción de línea de comandos para compilar y vincular aplicaciones multiproceso compatibles con POSIX y eso es lo que se debe usar.
En el momento de la compilación, la -pthreadopción manifiesta que se solicita la API de Pthread (puede haber varias API de subprocesos, por ejemplo, Solaris Threads) y define macros específicas de la plataforma ( _REENTRANTen Linux , _MTen Solaris).
En el momento del enlace, -pthreadenlaces en las bibliotecas necesarias (si las hay) que implementan el comportamiento de la API de Pthreads compatible con POSIX.
Lo anterior deja claro por qué -lpthreadno es ni necesario ni suficiente.