• Planeta Linux SHOP »
• VivaBSD! »
• VivaLinux! »
• VivaHardware! »
• VivaPHP! »

• Inicio
• Eventos
• Planeta
• Revisiones
• Traducciones

Necesitas con urgencia aquella aplicación. Ningún paquete binario se instala y los fuentes se niegan a compilar. No desesperen. Aun quedan los scripts, y aqui intentaremos develar sus ventajas.

Instalación de paquetes.

Muchas de las quejas de los usuarios Linux que se acaban de iniciar en las lides del software libre, se refieren a problemas en la instalación de los paquetes de software más utilizados. El primer intento, será descargar el paquete rpm (o eventualmente deb) e instalarlo. Con algo de suerte, y si nuestro sistema cumple con las dependencias, el paquete se instalará correctamente, y en la ubicación que haya elegido el creador del paquete, podremos encontrar el binario de la utilidad en cuestión, la documentación, etc. Es aquí donde pueden comenzar los contratiempos. Si Linux es uno solo, las distribuciones no lo son, y podremos encontrar diferencias mas o menos marcadas respecto al criterio de ubicación de las librerías, -término que debiéramos reeplazar de una vez por bibliotecas que es el correcto-, los binarios, etc. Es asi que podemos encontrar nuestros binarios en /usr/local/bin, /usr/bin, /opt/bin, etc. y eventualmente tendremos que indicar a algún paquete descarriado, adonde están las dichosas librerías Qt o GTK que no logra encontrar por sí mismo, sólo por dar ejemplos. Con algo de suerte, se puede indicar al instalador que ignore las dependencias que no se han cumplido, pero en ocasiones el problema va un poco mas allá, y vamos a hablar un poco más de eso, antes de llegar al tema central.

Compilación de código fuente.

Descartada la posibilidad de triunfar con un paquete en mano, lo que debe hacerse (en realidad yo prefiero esta alternativa), es descargar el archivo fuente (normalmente en formato .tar.gz, .tar.Z, .tgz o .tar.bz2). En realidad es importante perder el temor a compilar nuestras propias aplicaciones. No es nada del otro mundo, y nunca está de más saber cómo se hace. En general no suele ser una tarea tan titánica como puede indicarlo su nombre. Será interesante comenzar compilando algún fuente pequeño, y luego avanzar -al menos- hasta la recompilación del kernel. En cuanto al tiempo que demora este proceso, puede variar en función de la complejidad del programa, y del poderío del equipo sobre el que se haya encarado la tarea de compilación y podrá variar de entre pocos segundos, a varias horas. Respecto al cómo compilar, en general hay buena documentación adjunta a cada fuente, y los pasos casi siempre se circunscriben a:

./configure make make install

Pudiendo variar un poco. En ocasiones, será necesario adentrarse en las reglas (archivo Makefile), y ajustar alguna que otra trayectoria, indicar la ubicación de alguna librería, o el lugar donde queremos que se instalen todos los binarios que compilamos. No hemos considerado hasta ahora los errores de compilación, y aqui vamos. El primer paso, ./configure es un script que realizará una serie de pruebas sobre nuestro sistema, en busca de:

. Aplicaciones requeridas para compilar . Versiones mínimas de esas aplicaciones. . Librerías y versiones necesarias. . Variables de entorno, trayectorias, etc.

Si todo está correcto, el fiel configure se encargará de crear reglas de compilación adecuadas para nuestro sistema, y podremos pasar a los pasos siguientes. Si algo falla, podremos advertirlo en los mensajes que devuelve la ejecucion de configure. No atender este tipo de mensajes, pocas veces llevará a una compilación exitosa. Veamos algunos inconvenientes comunes:

Problema: Aplicaciones no encontradas

Solución: Asegurarse que están instaladas. (usando which o rpm -qa|grep aplicacion por ejemplo) Verificar que están en trayectoria. La trayectoria es una variable de entorno. Podemos verla con set|grep PATH, y será conveniente cambiarla en el archivo $HOME/.bash_profile. Buscar la forma de indicar estas dos situaciones, mediante el paso de parametros a configure. Para averiguar cuál es la lista de parámetros válida para el caso, tipear ./configure --help

Problema: Librerías no encontradas

Solución: Asegurarse que están instaladas. Usando locate o rpm. Constatar que luego de instaladas, ha quedado indicada su existencia. La trayectoria en que fueron instaladas debe quedar indicada al menos en el archivo /etc/ld.so.conf. Si no fuera asi, se agrega la línea correpondiente, y se ordena al sistema actualizar su lista de caminos a librerías, usando ldconfig. Intentar nuevamente el paso de parámetros como --with-weird-lib-in=/usr/local/lib/weird al momento de ejecutar configure

Problema: Versión incorrecta Solución: Sólo hay dos opciones:

configure tiene razón. Debemos actualizar nuestras librerías. Aunque parezca absurdo que necesitemos la versión 2.0.1-11, teniendo instalada 2.0.1-10b, los cambios entre una versión y otra, pueden ser importantes. Es posible intentar forzar la compilación con librerías viejas, con parámetros como --ignore-algo, creando enlaces o renombrando cosas, pero lo mejor es tener las últimas librerias instaladas. Nótese que la actualización de librerías puede requerir también, la actualización de otras dependencias propias de la librería, que deberán tenerse muy en cuenta, y normalmente se indican en la documentación de la librería.

configure es un idiota, incapaz de encontrar algo bien. Es frecuente con librerías como Qt, que sea precisa una versión u otra, y debamos tener varias instaladas. Para el caso de Qt en especial, las cosas están empezando a llevarse adelante con Qt 2.0, pero no está de más tener Qt 1.44, y en ocasiones eso no es tan visible para la configuración del compilador. La solución pasará tambien por indicar trayectorias acordes a nuestro caso, bien sea en ld.so.conf o con algún forcejeo en los parámetros.

Bien, ya tenemos nuestras reglas de configuración. Ahora compilamos y... Ouch!. Estos mensajes suelen ser más complicados de analizar que los anteriores, y quizá debamos retroceder varias líneas hasta encontrar las raíces de la falla. No nos detendremos mayormente aquí, puesto que estamos desviandonos ya demasiado del tema que nos une hoy, y el surtido de errores de compilación es mas bien grande. Sólo diremos que en ocasiones, es necesario tener instalados los fuentes del kernel, o paquetes de desarrollo, que podremos quitar sin problemas luego de compilar. Por ejemplo, será imposible compilar un plug-in para xmms, si no se tiene instalado xmms-devel-xxxx. Sólo la práctica concienzuda de compilación, nos dará pautas rápidas para la solución de este tipo de problemas.

La alternativa del software no-compilado

¿No hay forma de instalar? ¿La compilación tardaría días enteros en ese equipo? ¿Sería deseable cambiar algunos detalles de la interface, sin ser un gurú en C++? ¿Rápida migración a otras plataformas? ¿La velocidad de ejecución no es primordial? Bien, entonces es tiempo de adentrarse en la cuestión. Muchas veces se le ha achacado al software interpretado, el problema de la lentitud. Y en parte es cierto, pero si nos detenemos a pensar en las velocidades de proceso que manejamos en general, una demora de menos de dos segundos en la aparición de un bonito interfaz, puede ser impagable. Para quienes no hayan notado la diferencia, aplicaciones como control-panel y derivadas, o el interfaz gráfico para la recompilación del núcleo (visible con make xconfig), tienen un corazón interpretado, que puede analizarse en /usr/lib/rhs, para el primer ejemplo, y en /usr/src/linux/scripts para el segundo.

Entre las ventajas de adoptar software interpretado, para resumir podemos mencionar:

• 
• Acerca
• Contacto
• Foros
• Links