Установка старого софта на новый линукс (LD_ASSUME_KERNEL)

а может просто перекомпилировать программу? Кстати, слака 11 вполне везде запускается и там 2.4 ведро.

> а может просто перекомпилировать программу? Кстати, слака 11 вполне везде запускается и там 2.4 ведро.

программулина проприетарная и стоит больших денег, а слака не шибко то юзабильная.

virtualbox

> virtualbox

не. виртуальную машину буду использовать в только в крайнем случае, когда ничего больше нельзя будет сделать.

нужено решение без виртуализации.

> Собственно, нужно запустить старую софтину, скомпилированную еще под linux-2.4, на новом дистре линукса (желательно Ubuntu 8.04).

А собственно, ты ее запускать пробовал? Может, она просто работает?

LD_ASSUME_KERNEL - это "подсунуть программе старый glibc, который не пользуется новыми возможностями ядра", а такого старого glibc на новых системах просто нет.

> А собственно, ты ее запускать пробовал? Может, она просто работает?

Пробовал! Много раз пробовал! И на разных линуксах. Чего только не перепробовал за последние 3 дня:
которые заработали, но на которых не пошла прога: openSue 10.3, 10.2, Mandriva 2008, 2007, Ubuntu 8.04
которые либо не захотели устанавливаться, либо не запустились после установки: Suse 10.0, SLES 9.0, RHEL 4.0, CentOS 4.4

Прога пошла только на Mandriva 2006, но на ней нет драйверов для сетевой карты, котролеров IDE и почему-то не удолось завести 2 монитора.

> LD_ASSUME_KERNEL - это "подсунуть программе старый glibc, который не пользуется новыми возможностями ядра", а такого старого glibc на новых системах просто нет.

хм. и как же поставить (и подсунуть) старый glibc на в новой системе?

хм... врятли что то изменит но попробуй пустить ее под qemu-i386

поставь/скопируй в лтделтную папку старый glibc в пасах первым делом укажи эту папку. у меня так gcc разные стоят.

вообще-то слака весьма удобна :) как программа называется?

> как программа называется?

Inpres

> export LD_ASSUME_KERNEL=4.2.1

Не 4.2.1, а 2.4.1, и только на RedHat. Эта команда говорит glibc не использовать NPTL, а только linuxthreads. На более-менее новых глибцах это уже не работает. Т.е. система собрана без поддержки linuxthreads вроде как.

> Не 4.2.1, а 2.4.1, и только на RedHat.

На RH было не выше 2.4.1, на других дистрибутивах, например, Slackware-11.0, должно было быть не выше 2.4.33.3, Slackware-10.2 не выше 2.4.31 :)

Т.е. 2.4.1 подойдёт всем дистрам, где glibc собраны с двойной поддержкой тредов - и linuxthreads и NPTL.

Ошибки в студию. А так, я бы стал решать проблему распаковкой RPM-ов glibc от старого дистрибутива в какую-нибудь директорию (/old-glibc), где больше ничего нет, и запуском проги вроде такого:

/old-glibc/lib/ld-linux.so.2 --library-path /old-glibc/lib:/old-glibc/usr/lib:/lib:/usr/lib /path/to/bad/program

> Эта команда говорит glibc не использовать NPTL

Так все-таки действие LD_ASSUME_KERNEL не зависит от версии ядра, а зависит только от версии (сборки) glibc?

А можно ли собрать последнии версии glibc с двойной поддержкой потоков? Заработает ли в этом случае LD_ASSUME_KERNEL?

можно поставить uml или еще одну систему и запускать ее в chroot окружении, со своими libc и прочим

> А так, я бы стал решать проблему распаковкой RPM-ов glibc от старого дистрибутива в какую-нибудь директорию (/old-glibc)

Спасибо за совет, попробую. Я делат, что-то типа этого, но копировал не все библиотеки glibc, а те библиотеки от которых зависит исполняемый файл (ldd). В итоге вышла ошибка. Что-то типа:

libc.so.6: not find GLIB_2.4 (requered by libXp.so)

точно не помню.

@GLIBC_2.4

в Glibc 2.4 соответственно и выше возможно не сама прога ссылается , а что то из загруженных библиотек

libXp.sо )

> Так все-таки действие LD_ASSUME_KERNEL не зависит от версии ядра, а зависит только от версии (сборки) glibc?

Даже не от версии, а от сборки. Дистрибутивы, в которых LD_ASSUME_KERNEL работает, компилируют glibc дважды.

> А можно ли собрать последние версии glibc с двойной поддержкой потоков?

Нет, эту возможность разработчики glibc убрали (т.е. из пары linuxthreads+nptl оставили только nptl, т.е. с помощью LD_ASSUME_KERNEL выбирать стало нечего).

И все-таки, ошибки в студию.

> И все-таки, ошибки в студию.

то что запускаем выглядит так:

$ cat /inpres/inpres/inpres
#!/bin/sh

ulimit -c 0
umask 000

xset +fp /inpres/inpres/Fonts
xset fp rehash

export LD_ASSUME_KERNEL=2.4.2
export INPRES_MAIN=/inpres/inpres
export INPRES_RESR=$INPRES_MAIN/Resource/
export INPRES_DATA=/data/
export INPRES_TEMP=/tmp/
export LD_LIBRARY_PATH=$INPRES_MAIN/Lib:$LD_LIBRARY_PATH

LC_ALL=C

$INPRES_MAIN/mainmenu


если запускать прогу на только что поставленной Ubuntu 8.04, то результат таков

$ /inpres/inpres/inpres
/inpres/inpres/mainmenu: error while loading shared libraries: libm.so.6: cannot open shared object file: No such file or directory


если в скрипт inpres добавить строчку
export LD_LIBRARY_PATH=/home/inpres/libc6_2.3.6-0ubuntu20.5_i386/data/lib
т.е. использовать glibc 2.3.6, то результат таков

$ /inpres/inpres/inpres
/inpres/inpres/mainmenu: /home/inpres/libc6_2.3.6-0ubuntu20.5_i386/data/lib/libc.so.6: version `GLIBC_2.4' not found (required by /usr/lib/libSM.so.6)
/inpres/inpres/mainmenu: /home/inpres/libc6_2.3.6-0ubuntu20.5_i386/data/lib/libc.so.6: version `GLIBC_2.4' not found (required by /usr/lib/libICE.so.6)
/inpres/inpres/mainmenu: /home/inpres/libc6_2.3.6-0ubuntu20.5_i386/data/lib/libc.so.6: version `GLIBC_2.4' not found (required by /usr/lib/libXp.so.6)
/inpres/inpres/mainmenu: /home/inpres/libc6_2.3.6-0ubuntu20.5_i386/data/lib/libc.so.6: version `GLIBC_2.4' not found (required by /usr/lib/libXau.so.6)

>> А можно ли собрать последние версии glibc с двойной поддержкой потоков?

> Нет, эту возможность разработчики glibc убрали

да уж, убедился в этом на практике. при конфигурировании glibc пишет

...
configure: running configure fragment for add-on linuxthreads
linuxthreads disabled because nptl add-on is also in use
configure: running configure fragment for add-on nptl
...

Все таки попробуйте chroot. То есть создайте отдельный каталог (новый корень) и установите туда все нужные пакеты от старой системы (/bin/bash, glibc, Х-овые библиотеки). Замонтируйте туда dev и добейтесь, чтобы работал шелл в этом чруте "chroot /home/inpres/bin/bash".

> export LD_ASSUME_KERNEL=2.4.2

А почему бы эту строчку просто не убрать? Это я и имел в виду, когда писал "ошибки в студию".

> /inpres/inpres/mainmenu: error while loading shared libraries: libm.so.6: cannot open shared object file: No such file or directory

Это как раз от LD_ASSUME_KERNEL, поскольку в системе нет версии библиотеки libm, которая поддерживает такое старое ядро.

> если в скрипт inpres добавить строчку

> export LD_LIBRARY_PATH=/home/inpres/libc6_2.3.6-0ubuntu20.5_i386/data/lib

> т.е. использовать glibc 2.3.6, то результат таков

Это никоим образом не использование glibc-2.3.6. Действительно, программа все еще использует /lib/ld-linux.so.2 (т.к. именно он прописан в бинарнике в качестве ELF-интерпретатора), т.е. файл от новой версии glibc. Смешивание файлов от новой и старой версий glibc приводит к SEGFAULT'ам, поэтому надо запускать программу так (если, конечно, убирание LD_ASSUME_KERNEL не поможет):

/home/inpres/libc6_2.3.6-0ubuntu20.5_i386/data/lib/ld-linux.so.2 --library-path /home/inpres/libc6_2.3.6-0ubuntu20.5_i386/data/lib /inpres/inpres/mainmenu

И кстати, я не уверен, что в libc6_2.3.6-0ubuntu20.5_i386 нет NPTL.

Ну и подложить старые версии libXp, libSM, libICE, libXau и заодно уж и libX11 с libXaw туда же.

>> export LD_ASSUME_KERNEL=2.4.2

>А почему бы эту строчку просто не убрать? Это я и имел в виду, когда писал "ошибки в студию".

если ее убрать но будет использовать NPTL (вместо linuxthreads) и ничего не заработает

/inpres/inpres/mainmenu: relocation error: /inpres/inpres/mainmenu: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference

> И кстати, я не уверен, что в libc6_2.3.6-0ubuntu20.5_i386 нет NPTL.

он там есть

$getconf GNU_LIBPTHREAD_VERSION
NPTL 2.3.5

> /inpres/inpres/mainmenu: relocation error: /inpres/inpres/mainmenu: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference

Вот с этого и надо было начинать. Программу писал горе-программист, который не знает, что для доступа к errno полагается включать файл <errno.h>. В новых версиях glibc это не переменная, а макрос.

По хорошему это решается добавлением #include <errno.h> куда надо и перекомпиляцией, только исходников нет :( . Ну а так - действительно, только подсовывать старые библиотеки (не только glibc) и запускать через старый ld-linux.so.2.