Publicada enLINUX

Compilar software desde código fuente en Linux

No hay comentarios
compilar-software-desde-codigo-fuente-en-linux
compilar-software-desde-codigo-fuente-en-linux

Compilar software desde código fuente en Linux consiste en tomar los archivos escritos por los desarrolladores y convertirlos en un programa ejecutable para tu sistema. Dicho de forma sencilla: el código fuente es la receta, el compilador es la cocina y el binario final es el plato que puedes ejecutar.

En el uso diario de Linux, lo normal no es compilarlo todo manualmente. Lo habitual es instalar programas con el gestor de paquetes de la distribución: apt, dnf, pacman, zypper, Flatpak, Snap o paquetes preparados por el propio proyecto. Aun así, tarde o temprano aparece una guía que dice algo como:

./configure
make
sudo make install

Y ahí conviene entender qué está pasando antes de copiar comandos a ciegas.

En esta guía verás cómo compilar software desde código fuente en Linux, cuándo merece la pena hacerlo, qué herramientas necesitas, cómo funcionan los flujos clásicos con configure y make, cómo compilar proyectos con CMake, qué significa –prefix, cómo resolver errores frecuentes y qué precauciones tomar para no ensuciar el sistema.

👉 Y recuerda, si quieres aprender más de Linux, pincha en este curso de Linux gratis

👉 También te dejo por aquí una guía de comandos Linux por categorías

Paquetes frente a código fuente

Cuando instalas un programa con el gestor de paquetes, normalmente recibes un binario ya compilado. Por ejemplo, en Debian o Ubuntu:

sudo apt install htop

El paquete ya viene preparado para tu distribución. El gestor sabe dónde colocar los archivos, qué dependencias instalar, cómo actualizar el programa y cómo desinstalarlo después.

Cuando compilas desde código fuente, haces parte de ese trabajo manualmente. Descargas el código, instalas herramientas de compilación, resuelves dependencias, construyes el programa y decides dónde instalarlo.

La diferencia práctica es importante:

  • Con paquetes, el sistema gestiona instalación, actualizaciones y desinstalación.
  • Desde fuente, tienes más control, pero también más responsabilidad.

Compilar software desde código fuente no es «más Linux» ni necesariamente mejor. Es una herramienta útil cuando tiene sentido.

Cuándo tiene sentido compilar desde código fuente

Compilar desde fuente puede ser una buena idea en casos como estos:

  • Necesitas una versión más reciente que la disponible en los repositorios.
  • Quieres activar o desactivar opciones concretas de compilación.
  • Estás probando una rama de desarrollo o un parche.
  • El programa no tiene paquetes para tu distribución.
  • Estás aprendiendo cómo se construye el software en Linux.
  • Necesitas adaptar el programa a un entorno concreto.

Por ejemplo, puede que tu distribución tenga una versión antigua de una herramienta, pero el proyecto haya corregido un bug importante en la última versión publicada. En ese caso, compilar desde fuente puede ser razonable.

También puede ocurrir que un programa permita elegir características durante la compilación:

./configure --enable-feature-x --disable-feature-y
make
sudo make install

Ese nivel de control no siempre está disponible al instalar un paquete precompilado.

Cuándo no conviene compilar manualmente

No conviene compilar desde fuente si solo quieres instalar un programa común y tu distribución ya lo ofrece bien empaquetado. En ese caso, suele ser mejor usar el gestor de paquetes:

sudo apt install nombre-del-paquete

También puedes buscar alternativas mantenidas por el proyecto o por la comunidad:

flatpak search nombre-del-programa
snap find nombre-del-programa

Compilar manualmente tampoco es ideal si:

  • No sabes cómo desinstalar después lo que vas a instalar.
  • Es un programa crítico del sistema, como una librería base.
  • Vas a reemplazar archivos del sistema sin entender el impacto.
  • Solo necesitas probarlo una vez.
  • Existe un paquete oficial actualizado para tu distribución.

Una regla sencilla: si el gestor de paquetes resuelve tu necesidad, empieza por ahí. Compilar desde fuente debería ser una decisión, no un reflejo.

Herramientas básicas para compilar en Linux

Para compilar software normalmente necesitas un compilador, make y varias utilidades de desarrollo.

En Debian, Ubuntu y derivadas, el paquete habitual es:

sudo apt update
sudo apt install build-essential

build-essential instala herramientas básicas como:

  • gcc, el compilador de C.
  • g++, el compilador de C++.
  • make, la herramienta que ejecuta reglas de compilación.
  • Cabeceras y utilidades necesarias para construir paquetes sencillos.

Puedes comprobar que están disponibles con:

gcc --version
g++ --version
make --version

En Fedora:

sudo dnf groupinstall "Development Tools"
sudo dnf install gcc gcc-c++ make

En Arch Linux:

sudo pacman -S base-devel

En openSUSE:

sudo zypper install -t pattern devel_basis

Estas herramientas no garantizan que cualquier programa compile, pero son la base.

Dependencias: el punto más problemático

Un programa rara vez vive aislado. Puede necesitar librerías externas como OpenSSL, zlib, GTK, Qt, SQLite, libcurl, ncurses, FFmpeg u otras.

Al compilar, no basta con tener la librería en tiempo de ejecución. Muchas veces necesitas también los archivos de desarrollo: cabeceras .h, archivos .pc para pkg-config y enlaces para el compilador.

En Debian y Ubuntu, esos paquetes suelen terminar en -dev. Por ejemplo:

sudo apt install libssl-dev zlib1g-dev libcurl4-openssl-dev

En Fedora, suelen terminar en -devel:

sudo dnf install openssl-devel zlib-devel libcurl-devel

Un error común es ver algo como:

fatal error: openssl/ssl.h: No such file or directory

Eso no significa necesariamente que OpenSSL no esté instalado. Significa que faltan los archivos de desarrollo necesarios para compilar contra OpenSSL.

Otra pista frecuente aparece con pkg-config:

Package 'libcurl', required by 'virtual:world', not found

En ese caso, revisa si tienes instalado el paquete de desarrollo de la librería y la herramienta pkg-config:

sudo apt install pkg-config libcurl4-openssl-dev

Lee la documentación antes de compilar

Antes de ejecutar comandos, revisa los archivos del proyecto. Los nombres típicos son:

README
README.md
INSTALL
BUILD
CONTRIBUTING.md
docs/

Puedes listar el directorio:

ls

Y leer los archivos principales:

less README.md
less INSTALL

No todos los proyectos usan el mismo sistema. Algunos usan configure y make; otros usan CMake, Meson, Autotools, Ninja, Go, Rust, Python, Node.js u otro flujo. La documentación del proyecto manda.

Flujo clásico: configure, make y make install

Muchos proyectos tradicionales de C y C++ usan un flujo como este:

tar xf programa-1.0.tar.gz
cd programa-1.0
./configure
make
sudo make install

Cada paso tiene una función distinta.

Descargar el código y entrar en el proyecto

Si el proyecto distribuye un archivo comprimido:

wget https://example.com/programa-1.0.tar.gz
tar xf programa-1.0.tar.gz
cd programa-1.0

Si se descarga desde Git:

git clone https://example.com/proyecto.git
cd proyecto

Algunos proyectos clonados desde Git necesitan generar primero el script configure:

./autogen.sh

o:

autoreconf -fi

Eso depende del proyecto.

Qué hace ./configure

El script ./configure revisa el sistema: compilador, librerías, cabeceras, funciones disponibles y opciones de instalación. También prepara los archivos que usará make.

Ejemplo básico:

./configure

Ejemplo con prefijo de instalación:

./configure --prefix=/usr/local

Ejemplo instalando en tu carpeta personal:

./configure --prefix="$HOME/.local"

Si quieres ver las opciones disponibles:

./configure --help

Qué hace make

make lee un archivo llamado Makefile y ejecuta las reglas necesarias para compilar el programa.

make

En máquinas con varios núcleos, puedes acelerar la compilación usando varios trabajos en paralelo:

make -j"$(nproc)"

Si algo falla aquí, el error real suele estar unas líneas antes del final. No te quedes solo con el último Error 1. Busca mensajes como:

fatal error: archivo.h: No such file or directory
undefined reference to ...
cannot find -lxyz

Errores comunes en esta fase:

  • Falta una dependencia de desarrollo.
  • Se está usando una versión de compilador demasiado antigua.
  • Falta una herramienta auxiliar, como bison, flex, perl o python3.
  • El proyecto no soporta bien tu versión de la distribución.

Qué hace sudo make install

make install copia los archivos compilados a su ubicación final: binarios, librerías, manuales, iconos y otros recursos.

Si instala en rutas del sistema como /usr/local, necesitas privilegios:

sudo make install

Pero conviene no usar sudo durante la compilación. Compila como usuario normal:

make

Y reserva sudo solo para instalar:

sudo make install

Un error común es ejecutar:

sudo make

Normalmente no hace falta y puede dejar archivos generados como root dentro del directorio del proyecto. Si eso ocurre, después puedes tener errores de permisos al limpiar o recompilar.

Qué significa –prefix

–prefix indica el directorio base donde se instalará el programa.

Por defecto, muchos proyectos instalan en:

/usr/local

Eso suele colocar archivos en rutas como:

/usr/local/bin
/usr/local/lib
/usr/local/share

Instalar en /usr/local evita pisar directamente muchos archivos gestionados por la distribución, pero sigue siendo una instalación global.

Si estás probando algo, puede ser más limpio instalar en una ruta propia:

./configure --prefix="$HOME/.local"
make
make install

Observa que en ese caso no hace falta sudo, porque instalas dentro de tu usuario.

También puedes instalar en una carpeta temporal para inspeccionar qué se copiaría:

make DESTDIR="$PWD/package-root" install

Esto no siempre sustituye a un empaquetado real, pero ayuda a ver la estructura de instalación.

Flujo moderno con CMake

Muchos proyectos actuales usan CMake. CMake no compila por sí solo en el sentido clásico: genera archivos de construcción para otra herramienta, como Make o Ninja. Puedes ampliar conceptos en la documentación oficial de CMake, pero para empezar basta con entender el flujo básico.

Una práctica recomendable es compilar fuera del árbol de fuentes:

cmake -S . -B build
cmake --build build
sudo cmake --install build

Qué hace cada comando:

  • cmake -S . -B build: usa el directorio actual como fuente y crea la configuración en build.
  • cmake –build build: compila el proyecto.
  • cmake –install build: instala el resultado.

Para indicar un prefijo de instalación:

cmake -S . -B build -DCMAKE_INSTALL_PREFIX="$HOME/.local"
cmake --build build
cmake --install build

Si instalas en una ruta del sistema:

cmake -S . -B build -DCMAKE_INSTALL_PREFIX=/usr/local
cmake --build build
sudo cmake --install build

También puedes elegir tipo de compilación:

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build

Un error frecuente con CMake:

CMake Error: The source directory does not appear to contain CMakeLists.txt

Eso significa que no estás en el directorio correcto o que el proyecto no usa CMake. Busca el archivo:

find . -maxdepth 3 -name CMakeLists.txt

Ejemplo completo: compilar un programa

Imagina que quieres compilar un programa llamado ejemplo.

Primero instalas herramientas:

sudo apt update
sudo apt install build-essential pkg-config

Descargas el código:

git clone https://example.com/ejemplo.git
cd ejemplo

Lees instrucciones:

less README.md

Si el proyecto usa configure:

./configure --prefix="$HOME/.local"
make -j"$(nproc)"
make install

Compruebas que el binario existe:

ls "$HOME/.local/bin"

Si ~/.local/bin no está en tu PATH, puedes añadirlo en tu shell:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

Compruebas:

which ejemplo
ejemplo --version

Cómo desinstalar lo instalado con make install

Este es uno de los puntos más delicados. Cuando instalas con el gestor de paquetes, desinstalar es fácil:

sudo apt remove paquete

Cuando instalas con:

sudo make install

puede que el sistema no sepa qué archivos pertenecen a ese programa.

Algunos proyectos ofrecen:

sudo make uninstall

Pero no todos. Y para que funcione, normalmente necesitas conservar el directorio de compilación con el mismo Makefile.

Buenas prácticas:

  • Revisa si existe make uninstall antes de instalar.
  • Usa –prefix=»$HOME/.local» para pruebas personales.
  • Conserva el directorio de compilación si vas a necesitar desinstalar.
  • Considera crear un paquete nativo en vez de instalar manualmente.
  • Evita instalar encima de archivos gestionados por tu distribución.

Para proyectos con CMake, a veces existe un manifiesto de instalación:

cat build/install_manifest.txt

Borrar esos archivos manualmente debe hacerse con cuidado.

Usar checkinstall o crear paquetes propios

En algunos casos se usa checkinstall para crear un paquete simple a partir de make install:

sudo apt install checkinstall
sudo checkinstall

La idea es que el gestor de paquetes pueda registrar la instalación. No es perfecto, no sirve para todos los proyectos y no sustituye a un empaquetado serio, pero puede ser mejor que copiar archivos sin registro.

Para entornos profesionales, lo ideal es crear paquetes .deb, .rpm, usar contenedores o usar herramientas de empaquetado reproducible. Para un usuario que está aprendiendo, basta con entender el riesgo: instalar desde fuente sin registro complica la limpieza posterior.

Seguridad al compilar desde fuente

Compilar código fuente implica confiar en ese código. Si descargas un proyecto desconocido y ejecutas scripts como configure, autogen.sh o comandos de instalación, estás ejecutando código en tu máquina.

Buenas prácticas para compilar software desde código fuente:

  • Descarga desde la web oficial o el repositorio oficial.
  • Revisa releases, firmas o checksums si el proyecto los ofrece.
  • Evita ejecutar comandos con sudo salvo en el paso de instalación.
  • No ejecutes scripts aleatorios sin leer la documentación.
  • Prueba primero en una máquina virtual, contenedor o usuario no privilegiado si no confías del todo.
  • No reemplaces librerías críticas del sistema sin necesidad.

Si solo quieres probar una herramienta, instalar en tu usuario suele ser más seguro:

./configure --prefix="$HOME/.local"
make
make install

O con CMake:

cmake -S . -B build -DCMAKE_INSTALL_PREFIX="$HOME/.local"
cmake --build build
cmake --install build

Buenas prácticas para no ensuciar el sistema

Una forma prudente de compilar software desde código fuente:

  1. Leer la documentación del proyecto.
  2. Instalar solo las dependencias necesarias.
  3. Compilar sin sudo.
  4. Instalar en ~/.local si es una prueba.
  5. Usar /usr/local solo si quieres una instalación global manual.
  6. Guardar el directorio de compilación si necesitas desinstalar.
  7. Documentar qué comandos ejecutaste.

Resumen práctico

Compilar software desde código fuente en Linux es una habilidad muy útil, pero conviene usarla con criterio. El flujo clásico ./configure && make && sudo make install no es magia: configure revisa y prepara, make compila, y make install copia los archivos al sistema.

Para empezar con seguridad:

sudo apt update
sudo apt install build-essential pkg-config

Luego lee la documentación del proyecto y elige el flujo correcto.

Si usa configure:

./configure --prefix="$HOME/.local"
make -j"$(nproc)"
make install

Si usa CMake:

cmake -S . -B build -DCMAKE_INSTALL_PREFIX="$HOME/.local"
cmake --build build
cmake --install build

Usa sudo solo cuando realmente necesites instalar en rutas del sistema. Para pruebas, prefiere ~/.local. Y antes de instalar, piensa en la desinstalación: lo que el gestor de paquetes no registra, luego tendrás que gestionarlo tú.

La idea no es compilarlo todo manualmente. La idea es entender el proceso para poder decidir cuándo compilar desde fuente es la mejor herramienta y cuándo es más sensato dejar que tu distribución haga el trabajo por ti.

Comentarios

No hay comentarios aún. ¿Por qué no comienzas el debate?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *