PDF de programación - 1. Herramientas de desarrollo

1. Herramientas de desarrollo

Linux y Unix son muy populares entre los programadores, no solo debido a la abrumadora
variedad de herramientas y entornos disponibles sino también porque es un sistema

excepcionalmente bien documentado y transparente. En una máquina Linux, no tienes
que ser un programador para tomar ventaja de herramientas de desarrollo, pero cuando

trabajas con el sistema, debes conocer algo sobre las herramientas de programación
porque juegan un rol muy importante en la gestión de sistema Linux y en otros sistemas
operativos. Al menos debes poder identificar utilidades de desarrollo y tener alguna idea

de cómo ejecutarlas.

Este capítulo empaqueta mucha información en una pequeña pieza, pero no necesitas
dominarlo todo. Fácilmente puedes ojear el material y regresar más tarde. La discusión

de librerías compartidas es quizás lo más importante que debes conocer. Para entender
de dónde vienen las liberarías compartidas, primero necesitas tener alguna idea de cómo
se construyen los programas.

1.1. El compilador C

Conocer cómo ejecutar el compilador del lenguaje de programación C le permite aden-

trarse en los orígenes de los programas que se tienen en el sistema Linux. El código
fuente de la mayoría de las utilidades Linux, y varias aplicaciones de los sistemas Linux,
están escritas en C o C++.

Los programas en C siguen un proceso tradicional de desarrollo: Escribir los programas,

compilarlos, y ejecutarlos. Esto es, cuando escribes un programa en C y quieres ejecu-
tarlo, debes compilar el código fuente a una forma binaria de bajo nivel para que la

computadora lo entienda.

El compilador de C en la mayoría de sistemas Unix en el compilador GNU C, gcc,
aunque el nuevo compilador clang del proyecto LLVM está ganando popularidad. Los
ficheros de código fuente C terminan con .c.

1

1.1.1. Múltiples ficheros fuente

La mayoría de programas C son bastante largos y no es razonable ponerlos en un único
fichero de código fuente. Los ficheros mamut se desorganizan demasiado, y los compila-
dores a veces tienen problemas con ellos. Por lo tanto, los desarrolladores agrupan los

componentes del código fuente, teniendo cada pieza su propio fichero.

Cuando se compilan la mayoría de ficheros .c, no se crea un ejecutable como tal. En
vez de eso, se usan los compiladores con la opción -c en cada fichero para crear ficheros

objeto. para ver cómo funciona, digamos que tenemos dos ficheros, main.c y aux.c. los
siguientes comandos del compilador hacen la mayoría del trabajo de construcción del
programa:

$ cc -c main.c

$ cc -c aux.c

Los dos comandos precedentes compilan los dos ficheros de código fuente dentro de dos
ficheros objeto main.o y aux.o.

Un fichero objeto es un fichero binario que un procesador puede entender, excepto cuando
ha perdido algo. Primero, el sistema operativo no sabe cómo ejecutar un fichero objeto,

y segundo, necesitará combinar varios ficheros objeto y algunas librerías del sistema para
hacer un programa completo.

Para construir un ejecutable funcional desde uno o más ficheros objeto, debe ejecutar

el enlazador, el comando ld en Unix. Los programadores rara vez usan ld en una linea
de comando, porque el compilador C conoce cómo ejecutar el programa enlazador. Para
crear un ejecutable llamado myprog desde los ficheros objeto vistos antes, ejecutamos

este comando para enlazarlos:

$ cc -o myprog main.o aux.o

Aunque puede compilar múltiples ficheros fuente a mano, puede resultar difícil mantener
la pista de todos durante el proceso de compilación cuando el número de ficheros fuente se
multiplique. El sistema make es el estándar Unix tradicional para gestionar compilados.

2

1.1.2. Ficheros y directorios cabecera (Include)

Los ficheros de cabecera C son ficheros de código fuente adicionales que usualmente

contienen declaraciones de funciones con librerías. Por ejemplo, stdio.h es un fichero de
cabecera.

Desafortunadamente, un gran número de problemas de compilador se relacionan con los
ficheros de cabecera. La mayoría de los fallos ocurren cuando el compilador no puede

hallar los ficheros y librerías de cabecera. Hay algunos casos donde el programador olvida
incluir un fichero de cabecera requerido, causando que parte del código fuente no compile.

Solucionando problemas de fichero incluido Rastrear los ficheros incluidos correctos
no siempre es fácil. A veces hay varios ficheros incluidos con los mismos nombres en

diferentes directorios, y no está claro cuál es el correcto. Cuando el compilador no puede
hallar un fichero incluido, el mensaje de error luce como esto:

badinclude.c:1:22: fatal error: notfound.h: No such file or

directory

Este mensaje reporta que el compilador no halló el fichero cabecera notfound.h referen-

ciado por el fichero badinclude.c. Este error específico es el resultado directo de la línea
1 de badinclude.c:

#include <notfound.h>

El directorio incluido por defecto en Unix es /usr/include; el compilador siempre busca

allí a menos que usted le diga explícitamente que no. Sin embargo, puede hacer que el
compilador busque en otros directorios incluidos.

Por ejemplo, decirle que puede hallar notfound.h en /usr/junk/include. Puede hacer que
el compilador busque este directorio con la opción -I:

$ cc -c -I/usr/junk/include badinclude.c

Ahora el compilador no tendrá tropiezas en la línea de código en bainclude.c que refe-
rencia el fichero de cabecera. Hay que tener cuidado al incluir comillas (" ") en vez de

paréntesis angulares (< >), como esto:

3

#include "myheader.h"

Las comillas significan que el fichero cabecera no está en un directorio incluido en el

sistema sino que el compilador debe buscarlo en la ruta incluida. A menudo significa
que el fichero incluido está en el mismo directorio que el fichero fuente. Si encuentra
un problema con las comillas, probablemente está intentando compilar un fichero fuente

incompleto.

¿Qué es el pre-procesador C (cpp)? El pre-procesador C se encarga de buscar todos

los ficheros incluidos. Es un programa que el compilador ejecuta sobre su código fuente
antes de empezar a leerlo. El pre-procesador reescribe el código fuente a una forma que
el compilador entiende; es una herramienta para hacer que el código fuente sea fácil de

leer (y para proporcionar atajos).

Los comandos del pre-procesador en el código fuente se llaman directivas, e inician con
el carácter #. Hay tres tipos básicos de directivas:

Ficheros incluidos Una directiva #include instruye al pre-procesador para incluir un

fichero entero. Note que la indicación -I al compilador es una opción que causa
que el pre-procesador busque un directorio específico para incluir ficheros.

Definiciones macro Una línea como #define BLAH something le dice al pre-procesador
que sustituya something para todas las ocurrencias de BLAH en el código fuente.

La convención dicta que las macros aparezcan todas en mayúsculas, pero esto no
evita que los programadores a veces usen macros cuyos nombres parecen funciones

o variables.

Condicionales Puede marcar ciertas piezas de código con #ifdef, #if, y #endif. La
directiva #ifdef MACRO verifica para ver si la macro de pre-procesador MACRO está
definida, y las pruebas #if condition para ver si condition no es cero. Para ambas

directivas, si la condición que sigue a la «sentencia if» es falsa, no pasa la parte
del programa que está entre #if y la siguiente #endif al compilador. Si planea ver

cualquier código en C, debe haber usado eso.

4

1.1.3. Enlazar con librerías

El compilador C no sabe lo suficiente sobre su sistema para crear un programa útil
del todo. Necesita librerías para construir programas completos. Una librería C es una
colección de funciones comunes precompiladas que puede construir dentro de su pro-

grama. Por ejemplo, varios ejecutables usan la librería math porque provee funciones
trigonométricas y otras.

Las librerías se asignan primariamente en tiempo de enlace, cuando el programa enlaza-

dor crea un ejecutable de ficheros objeto. Por ejemplo, si tiene un programa que usa la
librería gobject pero se olvida de decirle al compilador que enlace la librería, verá errores
de enlace como este:

badobject.o(.text+0x28): undefined reference to ’g_object_new’

Las partes más importantes de estos mensajes de error están en negrita. Cuando el

programa enlazador examina el fichero objeto badobject.o, no puede hallar la función
que aparece en negrita, y en consecuencia, no puede crear el ejecutable. En este caso
particular, usted podría sospechar que olvidó la librería gobject porque ha desaparecido

la función g_object_new():

Para solucionar este problema, primero debe halla la librería gobject y después usar la
opción del compilador -l para enlazarla. Como con los ficheros incluidos, las librerías

están dispersadas en el sistema (/usr/lib es la localización por defecto del sistema),
aunque la mayoría de librerías residen en un directorio llamado lib. Para el ejemplo
precedente, el fichero de la librería básica gobject es libgobject.a, y el nombre de la

librería es gobject. Poniendo todo junto, usted enlaza el programa con algo como esto:

$ cc -o badobject badobject.o -lgobject

Debe indicar al enlazador sobre localizaciones de librerías no estándar; el parámetro para
esto es -L. Digamos que el programa badobject requiere libcrud.a en /usr/junk/lib. Para
compilar y crear el ejecutable, use un comando como este:

$ cc -o badobject badobject.o -lgobject -L/usr/junk/lib -lcrud

5

1.1.4. Librerías compartidas

Un fichero de librería que termina con .a (como libgobject.a) se llama una librería estática.
Cuando enlazas un programa a una librería estática, el enlazador copia el código de

máquina del fichero de librería dentro de su ejecutable. Por lo tanto, el ejecutable final
no necesita el fichero de librería original para ejecutarse, y por tanto, su comportamiento

nunca cambia.

No obstante, los tamaños de librerías siempre están aumentando, así como el número de
librerías en uso, y esto hace hace que las librerías estáticas sean ineficientes