Hola, y muchas gracias por la completa respuesta.

J.A. Gutierrez ha escrito:

> Azdo <azdo_b***yahoo.es> wrote:
>
> : estoy tratando de compilar las fuentes de un programa en un entorno un
> : tanto peculiar (un Irix). La versión de la libjpeg que trae no me
>
> entonces, deberias escribir en es.comp.os.unix

Bueno, escribí aquí porque no es que sea un tema específico de IRIX,
sino que funciona exactamente igual en Linux y porque tengo más
experiencia en Linux De todas formas, estoy usando todas las
herramientas GNU, iguales que las que se pueden encontrar en Linux.

>
> : sirve. Lo que he hecho es compilarla desde las fuentes mediante algo
> : como esto:
>
> : ./configure --prefix=/mi_directorio --program-suffix=LIM
>
> supongo que el prefijo es /usr/local

No, es otro directorio en el que quiero instalar mis librerías
especiales.

>
> : para que el resto de programas que dependían de la libjpeg antigua
> : sigan funcionando. Tras "make && make install" me deja la jerarquía de
>
> y para no machacar el sistema de instalacion de software
> nativo y su base de datos de ficheros instalados...
>

Correcto.

> Por otra parte, no especificas la version de IRIX que usas,
> pero en cualquier caso, te conviene saber que es probable
> que puedas descargarte una libjpeg mas actual sin salirte
> del sistema "oficial".

Realmente es lo primero que intenté, pero el repositorio oficial de
SGI tiene una libjpeg ligeramente desfasada.

> Concretamente, el paquete "Image Format Library 1.2.2"
> incluye la version 6a de la libreria jpeg. (y probablemente
> exista una version mas nueva de IFL, creo recordar que era
> descarga gratuita registrandose en las paginas de SGI)

Yo lo he descargado de http://freeware.sgi.com/

> : directorios de librerías, cabeceras y demás en el directorio
> : "/mi_directorio". Del sufijo "LIM" pasa completamente.
>
> no se necesita
>
> : El caso es que en el programa que quiero compilar, especifico la
> : librería jpeg que quiero usar con:
>
> : ./configure --with-jpeg=/mi_directorio
>
> : lo cual funciona perfectamente a la hora de compilar, dado que usa las
> : cabeceras .h de mi_directorio, aunque después compruebo que el
> : programa se está enlazando con las librerías dinámicas antiguas.
>
>
> Puedes hacer algo como:
>
> CC=cc CFLAGS="-Ofast" \
> CPPFLAGS="-I/usr/local/include" \
> LDFLAGS="-Ofast -L/usr/local/lib32 -rpath /usr/local/lib32" \
> ./configure \
> --with-jpeg=/usr/local \
> --with-libdir=/usr/local/lib32

Lo de --with-jpeg y compañía ya lo he hecho y funciona (la razón por
la que la libjpeg del sistema no me sirve es porque carece en algunas
estructuras del campo

void *client_data;

que usa el software que quiero compilar, por eso me da error) Cuando
uso una línea de configure similar a la tuya compila perfectamente,
pero luego los ejecutables y las librerías se quedan apuntando la la
libjpeg antigua, lo que me dará errores en el futuro.

He probado a usar '-rpath' igual que como la tienes tú en el
configure, pero resulta que el '-rpath' de sistema siempre se antepone
al mío, tal y como he podido comprobar con 'elfdump'. Tengo la
sensación de que todas estas herramientas se han pensado para permitir
la instalación de librerías en diferentes directorios del sistema,
pero no para que coexistan librerías iguales de diferente versión.

>
> : ¿Cómo puedo hacer para que se enlacen los programas con las
> : librerías nuevas?
>
> Creando las librerias dinamicas con numero de version
> superior a las del sistema y a~nadiendo /usr/local/lib[32]
> a LD_LIBRARY[N32]_PATH. Con eso el enlazador dinamico
> cargara las nuevas.
>
> Alternativamente puedes usar las opciones "-L" y "-rpath"
> Ejemplo:
>
> cc -mips3 -n32 foo.o -rpath /usr/local/lib32 -L/usr/local/lib32 -ljpeg
>
>
> : ¿Será más fácil enlazarlas estáticamente? En ese caso, ¿cómo se
> : haría?
>
> Y por ultimo, puedes enlazarla estaticamente, aunque no te lo
> recomiendo:
>
> cc -mips3 -n32 foo.o /usr/local/lib32/libjpeg.a
>

Gracias por estos últimos consejos, aunque realmente lo necesito hacer
mediante 'configure' y no invocando directamente al compilador.

Finalmente, pienso que debería ser posible. Después de todo, es más
o menos lo que hacen los 'cross-compilers', ¿no?