Cuando compilas un archivo fuente en C, el compilador no genera un ejecutable listo para correr, sino un archivo objeto (.o). Este archivo contiene código máquina, pero su componente más crítico para la integración es la tabla de símbolos. Un símbolo es una etiqueta que identifica un nombre (como una función o una variable global) en el espacio de direcciones. Durante la compilación, si usas una función que no está definida en el mismo archivo, el compilador no lanza un error; simplemente marca ese símbolo como referenciado (o undefined), dejando un hueco en la tabla de símbolos para que el enlazador (linker) lo resuelva más tarde.
El enlazador es el encargado de unir todos los archivos objeto y bibliotecas para crear un único flujo de ejecución. Su trabajo consiste en mapear cada símbolo referenciado con su definición correspondiente (la dirección de memoria real donde reside el código o los datos). Si el enlazador encuentra una referencia pero no una definición, el proceso falla. Si encuentra dos definiciones para el mismo símbolo, el proceso también falla por violación de la regla de definición única (One Definition Rule).
Para modularizar el código, utilizamos bibliotecas. Una biblioteca estática (.a en sistemas POSIX) es esencialmente un archivo “archivo” (ar) que empaqueta múltiples archivos .o. Cuando enlazas estáticamente, el enlazador extrae los objetos necesarios y copia su código directamente dentro de tu ejecutable; el resultado es un binario robusto y autónomo, pero más pesado y difícil de actualizar. Por el contrario, una biblioteca dinámica (como .so en Linux o .dylib en macOS) no se copia al ejecutable. En su lugar, el enlazador inserta una marca indicando que el símbolo se resolverá en tiempo de ejecución mediante el cargador dinámico del sistema operativo. Esto ahorra memoria y permite actualizar la biblioteca sin recompilar el programa, pero introduce la dependencia de que el archivo .so esté presente en el rpath o en LD_LIBRARY_PATH al ejecutarlo.
#include <stdio.h>
/*
* Declaración externa: le decimos al compilador que 'func_externa'
* y 'variable_global' existen, pero sus definiciones están en otro
* lugar (otro archivo .o o una biblioteca). El compilador deja
* una entrada "U" (undefined) en la tabla de símbolos del .o.
*/
extern void func_externa(int);
extern int variable_global;
int main(void) {
printf("Iniciando programa...\n");
printf("Valor de variable_global: %d\n", variable_global);
func_externa(42);
return 0;
}
/*
* DEFINICIONES:
* En un proyecto real, estas líneas estarían en un archivo 'lib_util.c'.
* Al estar en el mismo archivo, el compilador las ve como definiciones
* locales y las marca en la tabla de símbolos como 'T' (text/code)
* o 'D' (data).
*/
int variable_global = 100;
void func_externa(int valor) {
printf("Ejecutando func_externa con el valor: %d\n", valor);
}
/*
* NOTA PARA COMPILACIÓN MANUAL (Simulación de enlazado):
* -------------------------------------------------------
* Para ver cómo funciona el enlazador de verdad, imagina que
* separamos el código en dos archivos.
*
* 1. Compilar el objeto de la "librería":
* gcc -c lib_util.c -o lib_util.o
*
* 2. Crear una biblioteca estática:
* ar rcs libutil.a lib_util.o
*
* 3. Compilar el programa enlazando la biblioteca:
* gcc main.c -L. -lutil -o programa
* (Nota: -L. añade el directorio actual al path de búsqueda;
* -lutil busca un archivo llamado 'libutil.a' o 'libutil.so')
*
* 4. Inspeccionar símbolos con 'nm':
* nm -u programa | grep func_externa (Muestra símbolos no definidos)
* nm -g libutil.a (Muestra símbolos globales)
*/
Análisis del flujo de símbolos
En el ejemplo anterior, la función main llama a func_externa. Si intentaras compilar solo el archivo que contiene main sin la definición de la función, el compilador terminaría su trabajo sin quejarse, pero el enlazador lanzaría un error de tipo undefined reference to 'func_externa(int)'. Esto ocurre porque el símbolo está marcado como “pendiente” en la tabla de símbolos del objeto generado.
Al usar gcc main.c -L. -lutil -o programa, el enlazador realiza una búsqueda. El flag -lutil le indica que busque archivos que comiencen con lib y terminen en .a o .so con el nombre util. Un detalle crítico del enlazador (especialmente en ld de GNU) es el orden de los factores: el orden de los archivos en la línea de comandos importa. El enlazador procesa de izquierda a derecha. Por tanto, si main.o requiere símbolos de libutil.a, main.o debe aparecer antes en la instrucción. Si pones -lutil main.o, el enlazador verá libutil.a, notará que no necesita nada de ella todavía y pasará al siguiente, ignorando finalmente los símbolos que main.o necesita.
Si quisiéramos usar una biblioteca dinámica en lugar de la estática, el ejecutable resultante no contendría el código de func_externa. En su lugar, el encabezado ELF (el formato de archivo en Linux) contendría una sección DT_NEEDED, indicando al cargador que debe buscar libutil.so al momento de lanzar el proceso.
El error frecuente
Un error clásico que causa multiple definition of 'variable_global' ocurre cuando defines una variable global directamente en un archivo de cabecera (.h) y luego incluyes ese .h en varios archivos .c.
// error.h int contador = 0; // ERROR: Definición en un header
Cuando compilas archivo1.c y archivo2.c (ambos incluyendo error.h) y luego intentas enlazarlos, cada objeto contendrá su propia definición de contador. El enlazador, al intentar resolver el símbolo contador, encontrará dos entradas con la misma etiqueta y detendrá el proceso. La solución profesional es declarar la variable como extern en el .h y definirla en un único .c.
N° 7