Al estilo Pingüino #3: Compilando que es gerundio

En el anterior capítulo vimos, un poco a la carrera, la verdad, los diferentes métodos de instalación que proveían algunas de las distribuciones más conocidas. Si queréis profundizar en ello aquí tenéis un documento completísimo, nosotros poco más vamos a abundar sobre ello. La idea general es que, siempre que sea posible, es conveniente que uséis la interface gráfica de gestión de paquetes que incluya vuestra distribución favorita. En la gran mayoría de ocasiones, encontrareis ahí todo el software que necesitéis y será absurdo complicarse la vida innecesariamente.

 

Sin embargo, no podría escribirse una serie de artículos sobre Linux sin dedicar unos cuantos párrafos a hablar sobre compilación: El método universal de instalación de programas común a cualquier distro conocida. Las razones para esto son muchas:

Primero: No siempre encontraremos todo el software que queramos disponible en repositorios. Es raro, pero puede darse el caso y, en esas situaciones, tendremos que compilar nuestros propios ejecutables.

Segundo: Los programas disponibles en repositorios se compilan para ser lo más compatibles posible con la mayor cantidad de hardware. Es decir, que funcionaran perfectamente en nuestro equipo pero no, necesariamente, aprovecharan su potencia al máximo. Todavía hay  mucho software compilado para un solo núcleo cuando la gran mayoría de equipos actuales disponen de dos o de cuatro, por poner un ejemplo fácil (que habría que matizar muchísimo). Si queremos un programa que rinda al máximo en nuestra máquina tendremos que compilarlo específicamente para ella.

 

No, hay casos que ni compilando…

 

Tercero: Algunas de las características del software no se incluyen en las compilaciones “estándar” por considerarse su uso poco común. La gran mayoría de distribuciones prefiere programas ligeros, probados y con las características justas, antes de añadir funcionalidades poco usuales, poco testadas y que harían el software más pesado e inestable para añadir algo que poca gente acabaría usando. Si queremos esas características tendremos que compilar nuestros propios programas.

 

Cuarto: Es posible que suframos de “versionitis” aguda. Cabe la posibilidad de que pertenezcamos a esa extraña raza de seres incapaces de disfrutar de un programa versión “2.02.005a” si sabemos que ya existe por ahí la versión “2.02.005b”, aunque sepamos que, muy posiblemente, esa versión en desarrollo sea infinitamente más inestable que la actual. Para todos esos, ansiosos por estar a la última, no quedara más remedio que compilar ya que,  las versiones disponibles en repositorios, suelen ser algo más antiguas (MUCHO más antiguas si hablamos de Debian)

Quinto: Esta es la razón más importante de todas. Compilar Mola. Mola muchísimo. Eso de decirle a un colega que te has pasado la tarde recompilando el emulador de PSP para añadirle soporte para el orgasmatron y poder jugar al GOW manejando a Kratos con el cimbel no tiene precio. De verdad.

 

¡Ven aquí que te recompile, moza!

 

En fin, una vez que tenemos claras las razones por las que, alguna vez, tendremos que mancharnos las manos es hora de ponerse al tema.

Para compilar cualquier programa en Linux tendréis que hacer tres cosas:

1- Descargaros las fuentes.

2- Descomprimirlas en una carpeta cualquiera.

3- Escribir en la terminal “./configure”, “make” y, por último, “sudo make install”.

Fin del cursillo. ¡Ea! Pasamos a otra cosa.

¡Bueno vale! Me extenderé un poquito más, pero que conste que en el 95% de los casos no nos apartaremos ni un ápice de estas instrucciones generales. Realmente la compilación de cualquier software ha llegado a ser un proceso casi tan automático como la instalación del mismo a través de apt-get o yum. Pero vayamos por partes:

Lo primero será, por supuesto, contar con los programas necesarios para construir un paquete. Aquí no hay mucho que decir. Casi todas las distribuciones incluyen en sus repositorios un “meta-paquete” (esto es, un paquete que se compone de varios) que instala todo el entorno de compilación necesario. En Ubuntu y derivadas, este “meta-paquete” se llama build-essential, y bastara con instalarlo a través del centro de software para disponer de todas las herramientas necesarias (básicamente gcc y make).

Una vez contemos con las herramientas necesitamos el material para trabajar con ellas. Es decir, tendremos que descargar las “fuentes” del programa en el que estemos interesados.

 

Las fuentes, que nada tienen que ver con el agua, no son ni más ni menos que los archivos de texto donde esta escrito el programa en cuestión. Para que nos vayamos haciendo una idea, las fuentes de fuse son un archivo comprimido llamado fuse-1.0.0.1a.tar, Si lo descomprimimos (seguro que nuestra distro dispone de un gestor de paquetes comprimidos, no habrá más que hacer doble click sobre el archivo o bien, pulsar con el botón derecho del raton y elegir “descomprimir aquí” con el menú contextual) Tendremos una nueva carpeta llamada fuse-1.0.0.1a (el mismo nombre sin el .tar) llenita de archivos y subcarpetas. Observando con detenimiento veremos que casi todos los archivos acaban en “c” o en “h”, los acabados en “c” son las distintas funciones que componen el programa el sí, y los que acaban en “h” son las “cabeceras” de cada función.

Dos palabrejas mas, si. Las “funciones” son programas más pequeñitos que realizan alguna tarea para el programa principal, por ejemplo, si nuestro programa permite hacer capturas de pantalla tendremos una “función” que realice esa tarea, de ese modo, cuando el programa principal detecta cierta combinación de teclas (o más bien, cuando la función que lee el teclado le comunica al programa principal que se ha producido cierta combinación de teclas) Este le pide a la “función” llamada “screenshot” que capture la pantalla y la guarde con determinado nombre en determinado lugar.

Las “cabeceras” son las partes de los programas que ayudan a enlazar todo este conglomerado de “funciones” entre si y permiten trabajar (al menos en algunos leguajes de programación) de una forma más “modular”. Una descripción más detallada se escapa totalmente del objetivo de estos artículos.

 

No hará falta ponerse técnicos ¿no?

 

En fin, el caso es que, entre todo este “batiburrillo” de archivos el que más nos interesa tiene un nombre tan descriptivo que no haría falta ningún artículo para que le prestarais atención, se trata del README.

Así, en mayúsculas y todo, os lo encontrareis en el directorio de cualquier programa que decidáis compilar por vuestra cuenta. Y no tenéis que hacer más que eso: Leerlo.

En el caso que nos ocupa, vamos a ver que nos dice el README presente en las “fuentes” de fuse:

Primero nos encontraremos una pequeña descripción sobre qué programa es, que hace y lo mucho que molan los programadores que se lo han currado.

Luego vienen las cosas que realmente nos importan:

 

What you’ll need to run Fuse
—————————-
Unix, Linux, BSD, etc.

Required:

* X, SDL, svgalib or framebuffer support. If you have GTK+, you’ll get
a (much) nicer user interface under X.
* libspectrum: this is available from
http://fuse-emulator.sourceforge.net/libspectrum.php

 

Este fragmento de arriba nos está hablando de las dependencias, es decir, cualquier programa o librería sin los cuales no sería posible compilar lo que sea que estemos compilando. El primer paso, pues, antes de seguir adelante, consistirá siempre en comprobar que nuestro sistema satisface las dependencias necesarias y, de no ser así, instalarlas. La forma de hacerlo será la habitual, claro. Las buscamos en nuestros repositorios y, si no estuvieran disponibles, tendríamos que buscar las fuentes y compilarlas por nosotros mismos.

En este caso concreto la cosa esta fácil. La primera linea se refiere a unas librerías presentes en prácticamente cualquier distribución Linux actual con entorno gráfico. La segunda a una librería específicamente desarrollada para el trabajo con roms de Spectrum bajo Linux.

Un detalle a tener en cuenta es que, a la hora de compilar, tendréis que instalar los paquetes de desarrollo solicitados en las dependencias. Es decir, el programa fuse una vez compilado necesitara que este instalada la librería libspectrum Pero, a la hora de la compilación, necesitareis instalar el paquete libspectrum-dev que es el que contiene las fuentes y cabeceras que, seguramente, necesite el compilador para hacer su trabajo. Resumiendo, cuando instaléis dependencias, instalad tanto los paquetes “de uso” como los paquetes “de desarrollo” (.dev)

Una vez satisfechas las dependencias seguimos leyendo:

 

Optional:

* Other libraries will give you some extended functionality:
* libgcrypt: the ability to digitally sign input recordings (note that
Fuse requires version 1.1.42 or later).
* libpng: the ability to save screenshots
* libxml2: the ability to load and save Fuse’s current configuration
* zlib: support for compressed RZX files

 

Está claro ¿no? Aquí se nos habla de dependencias opcionales, sin estas librerías o programas fuse funcionara, pero no dispondrá de todas sus características. Es importante que, si queréis disponer de una determinada funcionalidad, os aseguréis de instalar estas dependencias ANTES de compilar el programa ya que, una de las cosas que realiza el paso de la configuración es comprobar el sistema y en base a las dependencias opcionales presentes habilitar o deshabilitar determinadas funciones en el programa. Es decir, si queréis hacer capturas de pantalla para escribir un artículo para Fase Bonus, os tendréis que asegurar de instalar la librería libpng antes de compilar fuse, si la instaláis después tendréis que volver a compilar el programa para que añada esa nueva función. Por supuesto esto es una generalización, una inmensa cantidad de software actual realiza ya estas comprobaciones en tiempo de ejecución, y determinadas opciones se habilitaran o no, dependiendo del  estado del sistema pero, por si acaso, no cuesta trabajo asegurarse de que vamos a poder capturar la pantalla final de “Abu Simbel”  ¿verdad?

Seguimos leyendo:

 

Building Fuse
————-

To compile Fuse (see below for instructions for the OS X native port):

$ ./configure

There are now some options you can give to configure; `configure
–help’ will list them all, but the most important are:

–with-fb        Use the framebuffer interface, rather than GTK+.
–with-sdl        Use the SDL interface, rather than GTK+.
–with-svgalib        Use the SVGAlib interface.
–without-gtk        Use the plain Xlib interface.

If glib is installed on your system, Fuse will use this for a couple
of things; however, it isn’t necessary as libspectrum provides
replacements for all the routines used by Fuse.

Another useful option is `–with-local-prefix=DIRECTORY’ which allows
you to specify that you have some the the libraries needed by Fuse in
`<DIRECTORY>/lib’ and the necessary header files in
`<DIRECTORY>/include’. If you specify the `–prefix’ option to tell
Fuse to install itself somewhere other than in /usr/local, that
directory will automatically be searched as well.

 

Como podemos ver, el archive README nos enseña todos los pasos necesarios para compilar el programa, con lo que leer cualquier artículo que se escribiera sobre ese tema seria una absoluta perdida de tiempo.

 

Que no, hombre, que es bromilla. Sigue leyendo.

 

Las opciones que podemos indicar al comando “configure” son las que, realmente, nos van a dar algún control sobre nuestra propia compilación del programa. Después del “./configure” nuestro ordenador se pasara un ratito lanzando mensajes rarunos por pantalla, si se produce algún error la configuración se detendrá y habrá que examinar esos mensajes para ver qué ha pasado, casi siempre alguna dependencia insatisfecha.

 

Then just:

$ make

and then

$ make install

if you want to place Fuse into the main directories on your system
(under /usr/local by default, although you can change this with the
–prefix argument to ‘configure’). You’ll probably need to be root to
do this bit.

Once you’ve got Fuse configured and built, read the man page 🙂

Note that if you’re using version of Fuse from Subversion rather than
one of the released tarballs, you’ll need to run `autogen.sh’ before
running ‘configure’ for the first time.

 

Y listo. Si seguimos estos últimos pasos tendremos fuse instalado y funcionando en nuestro sistema.

Como habréis visto, el procedimiento se aparta muy poquito del “./configure”+”make”+”make install” que dijimos al principio, pero es importante leer siempre el README para tener en cuenta cualquier pequeña variación que pudiera haber sobre la habitual forma de proceder.

En este caso, vemos que lo único de lo que se nos avisa es de que, si estamos compilando una versión en desarrollo, antes del procedimiento habitual deberemos ejecutar “autogen.sh”, un pequeño script que vendrá con las fuentes y que, al ejecutarlo, añadirá los archivos necesarios para que la compilación funcione sin problemas.

 

Y con este, creo, se acaban los artículos más “técnicos” de esta serie. A partir del próximo prometo ceñirme a lo que dije en un principio: “Emuladores para Linux” aunque, quien sabe, no soy demasiado bueno cumpliendo promesas.

Share

Acerca de logaran

Aficionado a todo menos al fútbol y a los toros. Friki convencido y a mucha honra. Estoy más que preparado para un apocalipsis zombi... Web | Twitter | Facebook | Google+
Esta entrada fue publicada en Artículos, Curiosidades. Guarda el enlace permanente.

17 respuestas a Al estilo Pingüino #3: Compilando que es gerundio

  1. Ya hay ganas de meterse en harina y conocer tus recomendaciones en cuanto a emuladores, que ando muy pez con emuladores y me vendrían bien 🙂

  2. Tranquilo Jefe que en el siguiente empezamos de verdad 😉
    Os vais a hartar de emuladores, Je Je,

  3. Compilar aplicaciones puede ser tan sencillo como escribir los 3 comandos mágicos mencionados, pero a veces se convierte en un infierno de dependencias de bibliotecas viejunas, incompatibilidades de código viejo con compiladores nuevos, problemas con punteros y demás zarandajas en arquitecturas de 64 bits… a veces hasta hay que tocar bastante el código…

    Yo más de una vez he dejado algún programa por imposible (sobretodo en entornos de compilación cruzada).

  4. doragasu dijo:
    Compilar aplicaciones puede ser tan sencillo como escribir los 3 comandos mágicos mencionados, pero a veces se convierte en un infierno de dependencias de bibliotecas viejunas, incompatibilidades de código viejo con compiladores nuevos, problemas con punteros y demás zarandajas en arquitecturas de 64 bits… a veces hasta hay que tocar bastante el código…

    Yo más de una vez he dejado algún programa por imposible (sobretodo en entornos de compilación cruzada).

    Sin duda compañero, pero te aseguro que en estos artículos no tocaremos aplicaciones problemáticas ni con un palo 😉

  5. o sea, que estoo hay que currárselo porque no es plug and play.

  6. A mi me gustaría saber que distribuciones de linux usaís, porque después de la última chapuza de ubuntu con Unity, y tras probar unas cuantas, no sé con cual quedarme. La única que tengo clara es Debian para un servidor web en un intel centrino 1,4 antiguo.

  7. Yo todavía sigo con Ubuntu 10.04 (que es LTS y por tanto tiene soporte para 3 años). La mayoría de renegados de Ubuntu parece que se están pasando a Linux MInt. Yo no la he probado, pero le daré una oportunidad.

    En cuanto a Unity, la verdad todavía está muy verde, tal vez en un futuro madure, pero por ahora estoy de acuerdo en que es bastante incómodo de usar.

  8. Deka Black dijo:
    o sea, que estoo hay que currárselo porque no es plug and play.

    Que no hombre, que no. Que esto es más Plug and play que Windows. Simplemente me he puesto en algún caso muy específico para tenerlo previsto cuando entremos en faena. Veras que instalar emuladores será cosa de un par de clicks, la consola la dejaré cono algo opcional para quien quiera complicarse un poco más pero, en ningún caso, será algo imprescindible :truestory:

  9. doragasu dijo:
    Yo todavía sigo con Ubuntu 10.04 (que es LTS y por tanto tiene soporte para 3 años). La mayoría de renegados de Ubuntu parece que se están pasando a Linux MInt. Yo no la he probado, pero le daré una oportunidad.

    En cuanto a Unity, la verdad todavía está muy verde, tal vez en un futuro madure, pero por ahora estoy de acuerdo en que es bastante incómodo de usar.

    Yo estoy con Arch, una distro cojonuda, fácil de usar y,a pesar de estar a la última (algo imprescindible para mí versionitis) muy estable. Si bien es cierto que de primeras puede parecer más complicada por el tema de no tener instalador gráfico.

    Mint es una gozada para iniciarse, de hecho es la que yo le instalo a los recién iniciados y aun no he tenido quejas 😉

    Con Unity no puedo. Hace que mi ordenador se sienta pesado, poco ágil. El tema de los lens me agobia, al menú global (que no es tan global como debería) me marea…en fin, que no es para mí, al menos por el momento…

  10. yo tambien uso ubuntu 10.04 y por lo que he leido cuando acabe el soporte me pasare a debian o a mint pero como todabia quedan años de soporte no es algo que ahora mismo me quite el sueño

  11. Creo que volveré a probar con Arch. Lo tuve hasta hace bien poco pero sólo instalalé KDE en inglés, y la verdad, no le dediqué tiempo a ponerlo en castellano ni nada.

    Voy a tener que darle la chapa a Logaran para dejar el PC fino fino antes de que vaya a la euskal en forma de recreativa y cargado de emuladores 😉

  12. Otro que sigue con el Ubuntu 10.04 LTS mientras dure. De momento no tengo pensado cambiarme por lo menos en el equipo de sobremesa, que es bastante viejuno.

  13. Yo nunca he tocado Arch, pero me suena haber leído que es un poco complicada de configurar, ¿no?

  14. LocoMJ dijo:
    Creo que volveré a probar con Arch. Lo tuve hasta hace bien poco pero sólo instalalé KDE en inglés, y la verdad, no le dediqué tiempo a ponerlo en castellano ni nada.

    Voy a tener que darle la chapa a Logaran para dejar el PC fino fino antes de que vaya a la euskal en forma de recreativa y cargado de emuladores 😉

    Arch es una de la distros que mejor se lleva con KDE, sin duda 😉

    Y no te cortes en preguntar lo que quieras que, en la medida de mis conocimientos (que no son muchos, no creas) Aquí estamos 😉

  15. doragasu dijo:
    Yo nunca he tocado Arch, pero me suena haber leído que es un poco complicada de configurar, ¿no?

    ¡Para nada!
    Tiene esa fama por que toda la configuración se hace modificando los archivos de texto necesarios, pero es mucho mas fácil de configurar o mantener que otras. Estoy seguro de que, para ti, no supondrá ninguna dificultad, ademas de que la wiki de la distribución es extraordinaria 😀

  16. Pues al final me has picado y me he instalado Arch en un portátil viejuno. La verdad que llevaba bastante tiempo interesado en instalarme una distro que fuera rolling-release, y por ahora la experiencia está siendo bastante buena.

    Los pros: va como un tiro, ya que no tiene toda la mierda que te meten todas las distros tipo Ubuntu.
    Las contras: pues que consume bastante tiempo tenerlo todo configurado, y de hecho algunas cosas que no están en los repos oficiales hay que compilarlas desde los repos AUR, lo cuál es sencillo (con la utilidad makepkg), pero come tiempo…

    Lo bueno es que al ser rolling release, supongo que no debería tener muchos problemas para tener la distro al día.

  17. Creo que esta tarde voy a optar por volver a tener Arch, pero esta vez habrá que configurarlo bien bien del todo. ¿Gnome3 o Kde?

    Por otra parte, los linuxeros de fasebonus deberiamos hacer piña 😛 Agregenme en tdocau at hotmail dot com

Deja un comentario

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