martes, 8 de octubre de 2013

QtCreator on Slackware 13.1

Para poder correr QtCreator 2.8.1; basado en Qt 5.1.1 en un slackware 13.1 de 64 es necesario actualizar la libreria libstdc++.

Para ello basta con bajar el gcc de los repos oficiales y compilarlo con la opcion --disable-multilib (para no usar las versiones de 32 bits de las librerias). Una vez compilado copiar el nuevo so, que en mi caso fue:
#cp x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6 /usr/lib64/libstdc++.so.6
Hice un backup de la libreria anterior (/usr/lib64/libstdc++.so.6.old) en caso falle algo. Hasta el momento todo bien.

Con eso se puede ejecutar QtCreator y otros programas que lo requieran. El error de compilacion cuando no se tiene la libreria actualizada es el siguiente:
./qt-linux-opensource-5.0.1-x86_64-offline.run: /usr/lib64/libstdc++.so.6: version on `GLIBCXX_3.4.15` not found ( required by qt-linux-opensource-5.0.1-x86_64-offline.run)

 

lunes, 23 de septiembre de 2013

passenger en un VPS con memoria limitada

Administrando un servidor web quise instalar redmine, para lo cual se necesita ruby, gems, etc.
Hasta ahi todo bien, en internet todo esta perfectamente documentado; sin embargo, al querer levantar el servidor con el modulo de passenger para apache tuve un problema (#passenger-install-apache2-module); pues al querer instalar el modulo salia el siguiente error:
#g++ -I.. -fPIC -g -DPASSENGER_DEBUG -DLINUX=2 -D_REENTRANT -
D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I/usr/
include/apr-0 -pipe -I/usr/include/xmltok -I/usr/include/openssl -Wall
-g -I/usr/include/apache2 -D_REENTRANT -Wall -g -I/usr/local/include -
c Hooks.cpp
virtual memory exhausted: Cannot allocate memory
rake aborted! 
Del mensaje de error vemos que el servidor se quedo sin memoria, ante lo cual, encontre la solucion de usar distcc. Es un programa que permite hacer la compilacion distribuida entre varias PC de una manera sencilla. Instale la aplicacion en el VPS y en mi PC. Luego de arrancar el daemon en ambos lados (#distccd --daemon --allow IP) configure las siguientes variables de entorno:
#export DISTCC_LOG=/tmp/distcc.log
#export DISTCC_DEBUG=1
#export DISTCC_DIR=/etc/distcc
#export DISTCC_BACKOFF_PERIOD=0

Finalmente para compilar:
#CC="distcc gcc" CXX="distcc g++"  passenger-install-apache2-module

Las dos primeras variables de entorno son para activar el debug y que el log sea el archivo indicado. La siguiente es el path en que se buscara el archivo hosts (por defecto es .distcc) que indica los hosts a los que se va a conectar. La ultima variable esta referida al funcionamiento de los PCs que ayudan a la compilacion (aka servidores). Cuando se compila, en caso de fallar alguna compilacion (por cualquier motivo) ese servidor entra a un periodo de "backoff" durante el cual no se le enviara ningun otro archivo para que compile durante un tiempo de 60 segundos. En mi caso eso no era deseable pues el VPS volaba con la memoria y era vital que la compilacion sea totalmente remota; que ningun archivo sea compilado de manera local; entonces desactive el tiempo de backoff colocandolo en cero.
Adicionalmente, para lograr este mismo cometido el archivo hosts (/etc/distcc/hosts) coloque lo siguiente:

200.65.99.104 localhost/1

Es importante el orden en que se coloquen los hosts, pues el primero en estar en la lista tiene mayor relevancia, así que se debería colocar en primer lugar a los servidores mas rápidos. Ademas, a localhost se le adiciono "/1" que indica que a lo sumo tendrá un solo proceso corriendo a la vez, para que no se sobrecargue mi VPS y se caiga la compilación. Leí en algunos foros que se podía colocar el valor de cero, para que se asigne cero procesos (o sea que no se asigne nada) al VPS; sin embargo el distcc retornaba error; parece que en versiones anterior si aceptaba el valor de cero, pero actualmente no lo hace.

Una ultima acotación  que es de vital importancia: se debe verificar las versiones de gcc que se utilicen en todos los puntos de la compilación distribuida, pues los .so que genera una versión no son necesariamente compatibles con otra. Esto me llevo a tener un error que hacia que la compilación se caiga; basto con cambiar la versión de gcc y la compilación, luego de mucho esfuerzo, se completo con éxito.

Obviamente que el log y el debug son opcionales para una compilación normal, pero obligatorias en caso que falle y se quiera ver en el error.

No olvidar de abrir temporalmente el firewall, hacer el NATeo correspondiente y de esperar un poco, que en mi caso fue bastante tiempo.

Documentación que encontre util:
http://distcc.googlecode.com/svn/trunk/doc/web/man/distcc_1.html

jueves, 7 de febrero de 2013

Magick Wand

Hacer un cambio de tamano con MagickWand es algo sencillo, sin embargo solo encontre algunos ejemplos en C; llevarlo a PHP no es muy dificil pero de todas formas dejo aqui el codigo:

Lo que hace es cambiar el tamano de una imagen gif animada. La imagen escalada mantiene la animacion.
$resource = NewMagickWand();
MagickReadImage( $resource, 'coales.gif' );
MagickResetIterator($resource);
while( MagickNextImage($resource) != FALSE )
        MagickScaleImage( $resource, 400, 200 );
MagickWriteImages($resource, 'copy.gif', TRUE);
?>

Cabe resaltar que en vez de MagickScaleImage() se pudo haber usado MagickResizeImage(), pero hice algunas pruebas y usando la primera funcion obtuve el tiempo de ejecuion:
real    0m17.027s
user    0m38.255s
sys     0m2.815s

Y para el segundo (MagickResizeImage)
real    0m21.899s
user    0m44.090s
sys     0m3.000s

Opte por usar el primero pues estoy desarrollando una aplicacion que no debe dejar esperando mucho tiempo a los usuarios y no importa mucho la calidad de imagen. Si se necesita calidad de imagen sugiero usar MagickResizeImage con algun filtro, la seleccion del filtro depende del uso.
http://www.imagemagick.org/Usage/filter/#best_filter
Aqui un articulo que habla de los filtros que se tienen en Magick


Para compilarlo manualmente (normalmente para slackware o gentoo) este articulo indica como hacerlo
www.ioncannon.net/php/75/how-to-compile-imagemagick-for-php-by-hand/

martes, 8 de enero de 2013

compile PHP con GD

Para poder usar imagenes con PHP debemos habilitar el GD que nos permitira trabajar con imagenes png, jpeg, gif, etc.
Para esto debemos compilar php con la siguiente linea de configuracion:
./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-libdir=lib64 --with-mysql --with-mysqli --with-curl=/usr/lib64 --with-curlwrappers --enable-mbstring --with-jpeg-dir=/usr --with-gd --with-png-dir=/usr

Esto es para un Slackware de 64bits. Tuve algunos problemas pues pese a colocar la opcion --with-jpeg-dir el phpinfo() no devolvia soporte para jpeg. Luego de compilar varias veces parece que habia que hacer ln a libjpeg que esta en /usr/lib64 a /usr/lib/ :
ln -s /usr/lib/libjpeg.so  /usr/lib64/libjpeg
Lo cual no tiene sentido pues se coloca la opcion --with-libdir=lib64; sin embargo, algunos foros sugieren que es script de configuracion no toma en cuenta la opcion. Luego de hacer eso, un make clean y compilar de nuevo funciono.