Fwd: Consulta LD_ASSUME_KERNEL

[Aldrin Gonzalo Martoq Ahumada]

Reenvio a la lista ya que por error solo respondi a Horst...

---------- Forwarded message ----------
From: Aldrin Gonzalo Martoq Ahumada <amartoq en dcc.uchile.cl>
Date: Aug 7, 2007 11:34 AM
Subject: Re: Consulta LD_ASSUME_KERNEL
To: "Horst H. von Brand" <vonbrand en inf.utfsm.cl>


On 8/6/07, Horst H. von Brand <vonbrand en inf.utfsm.cl> wrote:
> Aldrin Gonzalo Martoq Ahumada <amartoq en dcc.uchile.cl> wrote:
> > Estimados, me toca trabajar con software viejo y propietario
> > (principalmente IBM) y he notado que la variable de ambiente
> > LD_ASSUME_KERNEL ya no funciona como antaño.
> Hum... segun recuerdo vagamente, esto se usaba en el remoto pasado para
> hacer correr programas antediluvianos en las configuraciones de la epoca.
> Seguro que no hay nada mas nuevo?!

Yes, no hay nada mas nuevo, AFAIK.

> Mas detalles en <http://people.redhat.com/drepper/assumekernel.html>
> (vamos, es el primer hit en Google para LD_ASSUME_KERNEL!). Alli me
> parece que se responden tus consultas, y el porque "ya no funciona"... y
> el que si se requiere, es porque el programa esta mal hecho (razon demas
> para buscar alternativas...).
[.. mas abajo ..]
> > He buscado en internet, pero todos indican comentar las líneas de tus
> > scripts, no a que se debe la causa ni cuando ocurrio...
> Ver arriba.

Sorry Horst, ese documento esta desactualizado (data de 2004-5-12).
Eso explica como funcionaba LD_ASSUME_KERNEL, no dice _cual es la
alternativa de hoy_, si es que hay... De hecho, esa es mi pregunta
original. Parece ser que ya no es necesario utilizar LD_ASSUME_KERNEL
(todos los sitios en internet basicamente "corrigen" el problema
comentando LD_ASSUME_KERNEL), pero no encuentro la explicacion de como
esta funcionando ahora o como estan distribuyendo cada distro las
bibliotecas compatibles con las distintas ABI's en /lib, /lib/tls,
etc... No me he dedicado a ver el codigo fuente, google tiene
demasiadas referencias con la manera antigua...

Por ejemplo:
No entiendo como software compilado para trabajar con una ABI 2.2.5 o
2.4.1 "funciona" descomentando LD_ASSUME_KERNEL con un libc que dice
soportar ABI 2.6.9 ... Que cambio?
(Al final el software que uso en estas distros se cae por
LinuxThreads, que es otra pata...)

No entiendo porque al configurar LD_ASSUME_KERNEL, el linker se va a
buscar bibliotecas a /lib/tls o /lib/i686 si ya las que estan en /lib
si "soportan" las aplicaciones ...



> > Mi consulta es si esta caracteristica de LD_ASSUME_KERNEL se eliminó,
> > o hay que instalar algun paquete adicional. Segun tengo entendido,
> > esto es parte de libc.
> Es parte de /todas/ las bibliotecas compartidas, claro que c/u de cierto
> punto en adelante.

El mismo link nos corrige diciendo que es parte del linker. Las
distros distribuyen en /lib, /lib/tls y /lib/i686.

> >                                                         Tambien he
> > buscado referencias de cuando se eliminó el soporte a LinuxThreads en
> > la libc
> Ver p.ej. <http://en.wikipedia.org/wiki/LinuxThreads>. LinuxThreads se
> usaba en nucleos 2.4.x, los nucleos 2.6.x usan NPTL casi uniformemente
> (Red Hat fue pionero en esto).

AFAIK, LinuxThreads esta implementado completamente en userland, asi
que el nivel del kernel es irrelevante (en mis ejemplos, funciona en
Debian con kernel 2.6.18). El problema que hubo con NTPL fue que
necesitaban modificaciones al kernel, por eso demoro tanto...


> >         (y si existe alguna manera de reemplazarlo)
> Era una implementacion truja de POSIX Threads, que murio una muerte
> tranquila y merecida. QEPD.
> Su sucesor es NPTL, una implementacion bastante mas completa del
> estandar. En particular, tiene la ventaja que si funciona.

Parece que no ...

> >                                                     y no he
> > encontrado. Servirá copiar todas las bibliotecas de libc de un sistema
> > mas viejo y poner esta en un LD_LIBRARY_PATH que este _ANTES_ de la
> > /libc/; digamos /compat/oldlibc6/ ???
> Urgh.

Cierto, horrible.

> > Aqui hay algunos dumps de consola con los errores:
> >
> > ----- Ubuntu Feisty 7.04 ó Centos 5 ----
> > /opt/IBMJava2-131/jre/bin:# ./java -version
>
> Usa un Java mas nuevo, mas mejor. O consiguete alguna version an~eja de
> CentOS (creo que por alli aun mantienen CentOS 3...).

Java era solo un ejemplo, tengo varios productos que no puedo
reemplazar por versiones mas nuevas. Basicamente es para tener _el
mismo_ ambiente de produccion (que no es linux, sino AIX en un
POWERG5).

Hmm... necesito Xen entre otras cosas... Habia partido con CentOS 5...
al final lo que satisface todas mis requerimientos es Debian 4.0. Un
HINT para quienes trabajan con software propietario, hasta encontrar
la explicacion de fondo ...

--
Aldrin Martoq