Programemos Cosas

El añadido de librerías dinámicas (.so) al library path de Linux (LD_LIBRARY_PATH), debería ser automático con la instalación de cada paquete .tcl, pero tuve un caso particular de un programa que fallaba por referencias no resueltas. Una solución, programable desde bootsync.sh (en TinyCore Linux), es leer las librerías desde el path que no está encontrando y agregarlas a la variable del sistema LD_LIBRARY_PATH: # bootsync.sh if [ "$LD_LIBRARY_PATH" == "" ] then export path_sep="" fi if [ "$LD_LIBRARY_PATH" != "" ] then export path_sep=":" fi export LD_LIBRARY_PATH=$LD_LIBRARY_PATH$path_sep/usr/local/lib echo LD_LIBRARY_PATH echo $LD_LIBRARY_PATH

Fui advertido, en el sitio https://gna.org/ , de las contraindicaciones a la libertad de software de las aplicaciones que dependieran de Swing, por medio de un mensaje dispuesto en los formularios de alta de nuevos proyectos. Lo investigué. Si bien no hay conflicto con crear software libre que depende en otro no libre ( http://stackoverflow.com/questions/3111455/releasing-code-containing-java-swing-what-license ), la respuesta no me satisfacía. Yo quería que fuera libre íntegramente, incluidas las dependencias. GNU había acusado a Java de ser una trampa a la libertad, sin embargo, esta acusación fue retirada (no sin dejar una advertencia de peligro latente) tras aparecer varias implementaciones libres de la plataforma: https://www.gnu.org/philosophy/java-trap.html . La historia reconstruida por mí: Sun Microsystems no había liberado el código de Swing desde el principio, GNU trabajó (probablemente ambos en conjunto) para en el proyecto CLASSPATH ( http://www.gnu.org/softwa...