UD 1 - P13: Solución orientativa de la plantilla de entrega
Solución orientativa de la plantilla de entrega¶
Esta propuesta conserva los mismos apartados y preguntas que el README.md de la plantilla. Los datos de identificación, el entorno y las evidencias deben sustituirse por los del equipo de cada estudiante. Se aceptan respuestas redactadas de otra forma si son técnicamente correctas y se pueden comprobar.
1. Identificación¶
| Dato | Valor |
|---|---|
| Nombre y apellidos | Nombre y apellidos del estudiante o de la estudiante |
| Módulo | Entornos de desarrollo |
| Unidad | 1 |
| Práctica | P13 - Del código fuente al código ejecutable |
| Fecha | Fecha real de entrega |
2. Entorno de trabajo¶
Los valores siguientes son un ejemplo. La entrega debe recoger los datos reales del sistema utilizado.
| Dato | Valor |
|---|---|
| Sistema operativo | Linux, macOS o Windows |
| Arquitectura | x86_64, arm64 u otra arquitectura real del equipo |
| Versión de GCC | La salida relevante de gcc --version |
| Terminal utilizada | Bash, PowerShell u otra |
3. Código fuente¶
El archivo programa.c inicial puede contener:
#include <stdio.h>
int main(void) {
int num1 = 5;
int num2 = 3;
int resultado = num1 + num2;
printf("El resultado es: %d\n", resultado);
return 0;
}
Respuesta orientativa: Todo el contenido escrito en C dentro de programa.c es código fuente. Es legible y modificable por el equipo de desarrollo, pero el procesador no ejecuta directamente las instrucciones tal como aparecen en el archivo. Antes de compilar, el resultado esperado es 5 + 3 = 8, por lo que el programa debe mostrar El resultado es: 8.
4. Archivos y etapas del proceso¶
| Archivo | Herramienta que lo produce | Etapa | Qué representa | ¿Se puede ejecutar directamente? |
|---|---|---|---|---|
programa.c |
El equipo de desarrollo y su editor | Escritura del código fuente | Programa escrito en C, legible y modificable | No; debe traducirse con las herramientas del lenguaje |
programa.o |
GCC con la opción -c |
Compilación y ensamblado | Archivo objeto para el formato de destino, con instrucciones, símbolos y posibles referencias pendientes | Normalmente no; es una pieza intermedia, no un proceso completo |
programa o programa.exe |
Controlador de GCC y enlazador | Enlazado | Ejecutable preparado para un sistema y una arquitectura compatibles | Sí, si el entorno y sus dependencias son compatibles |
Comandos de referencia en Linux o macOS:
La salida inicial esperada es:
En Windows con MinGW-w64 y PowerShell, el enlazado y la ejecución pueden hacerse así:
El archivo objeto se genera sin enlazar porque se ha utilizado -c. El controlador de GCC invoca después al enlazador para combinar el objeto, el código de inicio y las bibliotecas necesarias. No es necesario entregar normalmente los archivos binarios generados: la tabla y las evidencias deben demostrar que existieron.
5. Preguntas sobre compilación y enlazado¶
5.1. Código fuente¶
Respuesta orientativa: El código fuente contiene instrucciones escritas en C, un formato pensado para que las personas puedan leerlo y mantenerlo. El sistema operativo y el procesador necesitan un formato traducido a instrucciones y estructuras que puedan cargar y ejecutar. Por eso el archivo fuente debe pasar por la cadena de herramientas antes de convertirse en un ejecutable.
5.2. Compilación¶
Respuesta orientativa: El comando gcc -Wall -Wextra -std=c11 -c programa.c -o programa.o procesa el código fuente, lo traduce y lo ensambla para generar programa.o. La opción -c evita el enlazado final. El objeto puede contener la implementación de main, símbolos y referencias externas que todavía deben resolverse en una etapa posterior.
5.3. Enlazado¶
Respuesta orientativa: El enlazador combina programa.o con el código de inicio y las bibliotecas necesarias, y resuelve referencias externas como la llamada a printf. El comando gcc programa.o -o programa produce el ejecutable para el formato, sistema y arquitectura de destino. Algunas bibliotecas pueden enlazarse dinámicamente y seguir siendo necesarias al ejecutar; no todas tienen por qué copiarse dentro del archivo final.
5.4. Omisión de una etapa¶
Respuesta orientativa: Si la compilación falla, no se obtiene un objeto válido para continuar. Si falta programa.o, el enlazado no puede utilizarlo. Si se omite el enlazado, no se obtiene un ejecutable completo. Además, si existen referencias sin resolver, el enlazador informa del error y no genera un ejecutable nuevo. Un ejecutable antiguo que permanezca en la carpeta no demuestra que la construcción actual haya terminado correctamente.
5.5. Objeto frente a ejecutable¶
Respuesta orientativa: Ambos archivos pueden contener datos binarios, pero cumplen funciones distintas. programa.o es un archivo objeto intermedio: puede contener instrucciones, símbolos y referencias que necesitan reubicarse o resolverse. programa o programa.exe tiene el formato de carga que espera el sistema operativo y está preparado para iniciar un proceso en un entorno compatible.
6. Modificación a 17 y 25¶
6.1. Predicción¶
- Resultado esperado antes de ejecutar:
El resultado es: 42. - Motivo por el que hay que volver a compilar y enlazar: modificar
programa.cno actualiza automáticamenteprograma.oni el ejecutable anterior. Hay que generar de nuevo el objeto y enlazarlo para que los artefactos incorporen los valores17y25.
6.2. Comandos y resultado observado¶
Después de cambiar las dos asignaciones en programa.c, los comandos de referencia en Linux o macOS son:
En Windows con MinGW-w64 se puede generar y ejecutar programa.exe con:
Resultado de la segunda ejecución:
7. Buenas prácticas reutilizables¶
| Buena práctica | Justificación |
|---|---|
| Separar la compilación del enlazado | Hace visibles las etapas y permite localizar si el fallo está al generar el objeto o al crear el ejecutable. |
| Conservar el código fuente y distinguir los artefactos | programa.c es la fuente de trabajo; programa.o y el ejecutable son resultados regenerables y no deben confundirse con ella. |
| Leer los diagnósticos y comprobar cada artefacto | Los mensajes indican la etapa que ha fallado y verificar los archivos evita aceptar como nuevo un artefacto antiguo. |
| Registrar el entorno, los comandos y repetir la construcción tras modificar el fuente | Facilita reproducir el proceso y garantiza que el ejecutable refleja la última versión del código. |
8. Evidencias¶
Una evidencia válida debe proceder del entorno real de la entrega. Por ejemplo, en Linux o macOS se puede incluir un listado como este, sin inventar tamaños ni fechas:
En Windows se puede utilizar Get-Item programa.c, programa.o, programa.exe o una captura equivalente. Si se incluyen imágenes, deben guardarse en evidencias/ y enlazarse desde el README.md. No es necesario subir normalmente programa.o ni el ejecutable.
9. Reflexión final¶
El código fuente es el archivo que escribe y mantiene el equipo de desarrollo. GCC lo transforma en un archivo objeto cuando se utiliza -c; ese archivo contiene una parte del programa, pero todavía puede tener referencias pendientes. El enlazador combina el objeto con el código de inicio y las bibliotecas necesarias para producir un ejecutable. El ejecutable depende del sistema operativo, del formato binario, de la arquitectura y, en algunos casos, de bibliotecas dinámicas disponibles en el equipo de destino. Por eso un ejecutable generado en un entorno no tiene por qué funcionar sin cambios en otro.
Como ampliación, CPython también puede compilar el código fuente a bytecode y guardar archivos .pyc, pero ese bytecode no es el archivo objeto nativo .o ni el ejecutable de C generado en esta práctica.
10. Lista de comprobación¶
- He completado la identificación y el entorno de trabajo.
- He incluido
programa.ccon el código solicitado. - He documentado
programa.oy el ejecutable generado. - He respondido las preguntas sobre compilación y enlazado.
- He repetido el proceso con
17y25y he obtenido42. - He identificado al menos cuatro buenas prácticas.
- He añadido las evidencias solicitadas.
- He escrito la reflexión final.