compiler - gcc flags list
¿Por qué tengo que enlazar explícitamente con libm? (3)
Posible duplicado:
¿Por qué tienes que vincular la biblioteca de matemáticas en C?
Cuando escribo un programa que usa funciones de la biblioteca math.h
, ¿por qué tengo que enlazar explícitamente con libm
aunque sean parte de la biblioteca estándar de C?
Por ejemplo, cuando quiero usar la función sin()
necesito #include <math.h>
pero también necesito pasar -lm
a GCC. Pero para cualquier otra biblioteca de la biblioteca estándar, no tengo que hacer eso. ¿Por qué la diferencia?
En los viejos tiempos, los enlazadores eran lentos y la separación del código matemático en su mayoría no utilizado del resto hacía que el proceso de compilación fuera más rápido. La diferencia no es tan grande hoy, por lo que puede agregar la opción -lm
a la configuración predeterminada del compilador.
Tenga en cuenta que el encabezado <math.h>
(o cualquier otro encabezado) no contiene código. Contiene información sobre el código, específicamente cómo llamar a funciones. El código en sí está en una biblioteca. Quiero decir, su programa no usa la "biblioteca <math.h>
" , usa la biblioteca math y usa los prototipos declarados en el encabezado <math.h>
.
En realidad, la razón por la que normalmente no necesita vincularse con libm para la mayoría de las funciones matemáticas es que su compilador las integra. Su programa no se puede enlazar en una plataforma donde este no es el caso.
Es la misma razón por la que debe vincularse explícitamente con libpthread
en la mayoría de las implementaciones. Cuando se agrega algo nuevo y aterrador a la biblioteca estándar, por lo general, primero se implementa como una biblioteca adicional que reemplaza algunos de los símbolos en la implementación de la biblioteca estándar anterior con versiones que se ajustan a los nuevos requisitos, mientras que también agrega muchos Nuevas interfaces. No me sorprendería si algunas implementaciones históricas tuvieran versiones separadas de printf
en libm
para la impresión en punto flotante, con una versión "light" en el libc
principal que carece de punto flotante. Este tipo de implementación en realidad se menciona y se recomienda para sistemas pequeños en el documento de fundamentos de ISO, si recuerdo correctamente.
Por supuesto, a largo plazo, la separación de la biblioteca estándar de esta manera genera más problemas que beneficios. La peor parte es probablemente el aumento en el tiempo de carga y el uso de memoria para los programas vinculados dinámicamente.