Чтоб мой ELF с любой установленной LIBC запускался

В продолжении темы про совместимость с разными Линуксами, BSD и сопутствующими стандартными либами.



Всё раздумываю как решить вопрос с версией LIBC. Т.к. версия стандартной сишной либы попадает в заголовок эльфа, интерпретатор отказывается потом запускать эльф, если на целевой платформе окажется другая версия LIBC (старее или новее - не важно). Кто как с этим борется? Имеет ли смысл попробовать написать для этого свой интерпретатор?



Подозреваю, что проблема имеет место и в совместимости с другими либами: GTK, SDL, ... Поэтому просто избавиться от LIBC (перейти на системные вызовы или на статические моды LIBC) глобально проблемы не решает.

 

Quantum

Написать "libc-independent" патчер для патча версии требуемой libc твоих эльфов.

 

IceStudent

Чтоб инсталлятор определял текущую версию нужных либ и патчил эльфы? Такое решение может не устроить юзеров, но идея интересная. Об этом где-то можно почитать?

 

тогда это может сделать скрипт на перле или питоне

 

Asterix

Питон или перл есть не у всех. В DSL нет ни того, ни другого.



Хотелось бы узнать как универсальнее всего определять текущую версию LIBC (перебором по именам файлов libc* или можно проще?) А что если вместо патча создать символьную ссылку?

 

я бы сделал так:

gcc --print-file-name=libc.so

 

r90

gcc может не оказаться Не понимаю почему такие тривиальные задачи в линуксе решаются полным извратом Как же люди умудряются делать неопенсорсное ПО для *никсов?! Одними syscalls сыт не будешь



Кстати, анализировал недавно coredump после падения одной утилиты и после нескольких часов напряженных раздумий пришёл к выводу, что в дампе порядок регистров не соответствует описанию из манфайла. Этот шедевр был обнаружен только в последней версии DSL. В других дистрибутивах порядок регистров оказался правильным.

 

:-/ а что там наточняк будет кроме ядра?

линукс --- это ядро. и в каждом дистре есть свой собственный способ. кто-то использует rpm, кто-то apt, кто-то emerge...



а! кстати, попробуй поковырять autoconf/automake --- `./configure' умеет много чего выяснять, почему бы не использовать это для создания какого-нибудь system-config.txt. А чтоб не тянуть в депендансах autoconf, automake и m4 можно создать скрипт configure на другой тачке, другое дело, что этот скрипт будет устаревать со временем. Но при этом ./configure в большинстве случаев присутствует в OpenSource пакетах вида tar.gz и ничего.

напр. с дровами nvidia сделано следующим образом, есть скрипт NVIDIA-...sh, в котором просто лежит tar.gz архивчик. Скрипт его разархивирует в закрытые .o файлики, .c обёртки для .o и Makefile, который компилирует .c, и потом компонует .ko... Правда всё это работает только при наличии sh, tar, gzip, fileutils, make, gcc, ld, и сорцов ядра.



Как там сделано в Sun'овском jre или бинарных пакетах OpenOffice, не знаю, не вникал. Но они вроде ничего не компилируют. Хотя твёрдой уверенности в этом у меня нет.

 

r90

К примеру, по умолчанию в 10ом и более старых дистрибутивах Mandrake не ставится gcc (с новыми ещё не работал). Asterix обнаружил, что и в последнем SuSe нет gcc, но можно доустановить. И в DSL нет gcc, хотя тоже можно доустановить после некоторых танцев с бубном. Во всяких "неминималистических" LiveCD обычно gcc присутствует.

Я бы предпочёл тарбол вообще без инсталлера, т.к. не все дистрибутивы дружат с rpm. Оказалось, что rpm - надстройка над каким-то старым архиватором, но и его может не оказаться. Опять таки в DSL его не оказалось, но есть GNU Tar.

Попробую. Не знаком с этой утилитой.

Грубо говоря, офигеваю просто...

 

<font color="#aaaaaa]И после этого еще кто-то защищает linux =)</font><!--color-->

 

зря. напр., ядро может быть скомпилировано с опцией CONFIG_REGPARM=y, которая говорит чтоб внутри ядра использовалась регистровая передача аргументов, вместо стандартного cdecl. И как nvidia будет с этим бороться без gcc? делать на сайте форму типа: дайте нам ваш .config, и мы выберем для вас дрова, скомпилированные таким образом, что modprobe на них не повлечёт за собой kernel panic?

не совсем всё так просто. rpm, также, ведёт учёт установленных пакетов, файлов и их версий, что, собственно, и должно тебя интересовать.

ну что тут сделаешь... разве что так:

if which apt >/dev/null 2>&1; then

config_install_with_apt

elif which rpm >/dev/null 2>&1; then

config_install_with_rpm

elif which emerge >/dev/null 2>&1; then

config_install_with_emerge

elif which autoconf >/dev/null 2>&1; then

config_install_with_autoconf

elif ! try_config_by_hand

echo "Dear user, please, ask your guru to make good installation of normal disro, or you will be unable to use this cool program."

fi

 

r90

Основания для подобного изврата бесспорно есть, я и не говорю, что в nvidia дураки сидят, но от этого легче не становится.

Эти соглашения совместимы, если я правильно понял о чём речь (о system calls, да?). Можно пихать параметры в стек и одновременно передавать их в регистрах.

Для коммерческого пакета ПО это очень полезная фича. У меня несколько иной профиль и инсталлер будет скорее обузой. Правда, сейчас в инете можно найти книги в формате CHM с инсталлером для винды...

Одно мне нравится в Линуксе - шелл.



По аналогии с nvidia появилась идея распространять обьектники (не сишные сорсы, а уже откомпилированные обьектники) и линковать их на целевой машине. Без GCC, конечно, работать не будет, но как временное решение сойдёт. Спасибо за дельные советы!

 

нет. о вызовах функций ядра из ядра. интерфейс user <-> kernel никак от этого не меняется.

 

На оригинальность этой идеи уже не могу претендовать. Как оказалось, fasm для Unix/libc распространяется именно так.



r90

С ядром ещё не связывался, но всё равно странно, что нельзя делать вызовы совместимыми с обоими сборками. Понятно, что совместимость Linux/BSD страдает из-за вражды между разработчиками обоих ядер, но почему никто не задумывается о совместимости хотя бы в рамкох одной оси?! А gcc в дрова может баг засадить и будет весело.

 

по сути эта опция просто добавляет при сборке ядра к каждому вызову gcc -mregparm=3. syscall'ы это не затрагивает, они всё равно все проходят через system_call, которая выглядит так (я развернул макросы и вырезал несущественное):

Код (Text):

1. ENTRY(system_call)
2.     pushl %eax          # save orig_eax
3.         cld
4.         pushl %es
5.         pushl %ds
6.         # pushl <всякие прочие регистры>
7.         ...
8.         pushl %edx
9.         pushl %ecx
10.         pushl %ebx
11.         # всякие дополнительные инициализации/проверки
12.         ...
13.         call *sys_call_table(,%eax,4)
14.         ...

а все определения, собственно, syscall'ов (указатели на которые лежат в sys_call_table) имеют атрибут __attribute__((regparm(0)))



CONFIG_REGPARM же затрагивает только внутренние функции ядра, то есть те, которые нельзя вызвать из user-space, даже через заглушку system_call. Это делается исключительно ради производительности внутри ядра, и если мы начнём складывать там аргументы и в стек и в регистры ради вызова каждой функции, то смысла в этом мало. Да ещё замучаешься обучать gcc делать такой код, либо переписывать ядро на асме.

 

) вспоминается вирус, найденный недавно Касперским, который не хотел работать, до тех пор пока Торвальдс, посмотрев на это, не написал патч к gcc.



Вообще, сейчас вроде как Novell завелась приделать к линуху приятностей для бинарных дров. А так... Я вылетал из системы с kernel panic из-за дров, но это был единственный случай, когда я собрал ядро с этой самой CONFIG_REGPARM, а дрова для момеда (распространямые в стиле nvidia) оказались не в состоянии это пережить.

 

Quantum

Всё раздумываю как решить вопрос с версией LIBC. Т.к. версия стандартной сишной либы попадает в заголовок эльфа, интерпретатор отказывается потом запускать эльф, если на целевой платформе окажется другая версия LIBC (старее или новее - не важно).

Обычно, совместимость сверху вниз в рамках одной подверсии присутствует, так точно было в GLIBC_2.1 и 2.2. Кстати, странно, что при наличии более поздней версии - файл не запускается, у меня стоит glibc-2.3.1, и отлично идут файлы собранные со всеми старыми версиями (потому что в библиотеке присутствуют все символы старых версий). Как вариант, можно собрать бинарник для самой старой версии и убрать строку о версии libc/glibc из его таблицы строк.



Имеет ли смысл попробовать написать для этого свой интерпретатор?

Интерпретатор нужен для несколько других целей, здесь он не поможет.



Понятно, что совместимость Linux/BSD страдает из-за вражды между разработчиками обоих ядер, но почему никто не задумывается о совместимости хотя бы в рамкох одной оси?!

Так развивается все постоянно! Одно только api и структуры к usb-стеку меняли раз десять. Я запарился в свой драйвер правки и обходы вносить. Как сделала nvidia/ati: всю ядро-зависимую часть они сделали открытой и собирают по месту, преобразуя функции ядра в свои, а дальше идет большая библиотека, одна на BSD/Linux, потому что внутренний api у них стандартизован.



Ядро linux - это как вавилонская башня: куча кода от абсолютно разных разработчиков собранная под общим стилем. С libc ситуация еще хуже, т.к. там пытаются поддерживать частичную обратную совместимость со всем этим зоопарком, кроме того проект отстает от изменений в ядрах.

 

<font color="#999999]кстати, а нвидия уже поддерживает аппаратное ускорение под linux'ом?</font><!--color-->

 

что значит "уже"? Как минимум последние года три --- всё то время, как я использую видяху от nvidia --- всё замечательно ускоряется.

 

тогда наверно меня интересует для относительно новых

карточек 6600GT, для них поддерживается?