freepascal.ru

Хочу добиться возможности создания бинарных исполняемых файлов,
совместимых с (почти) всеми версиями Linux !

Например, эта программа собирается (статически) на CentOS 7 64-bit и
благополучно выполняется на Debian (11 - ?) 64-bit :

Код: Выделить всё

program hello;
begin
   whileln('Hello !');
end.


Если взять что-нибудь посложнее ( примеры из Wiki по fpWeb ),
то, вне зависимости от статической или динамической сборки,
получаю на Debian (11 - ?) 64-bit ошибку :
Segmentation fault

Есть ли какие подходы заставить это работать ?

grot писал(а):Хочу добиться возможности создания бинарных исполняемых файлов,
совместимых с (почти) всеми версиями Linux !

Как только четко сформулируете, что такое "версия Linux", так сразу же сможете грамотно сформулировать задачу. До этого момента тыкаться вслепую бессмысленно.

Хочу как в Windows , где :
32-bit EXE будет запускаться везьде , начиная с Windows-95 и заканчивая теми версиями, котрые еще даже не вышли.

В Linux пусть это будет любой 64-bit дистрибутив с любой версией kernel , c любой версией LibC, любой версией (...) и т.д.

Речь идет о статически-собранном бинарнике, у которого нет зависимистей на посторонние библиотеки !

grot писал(а):В Linux пусть это будет любой 64-bit дистрибутив с любой версией kernel , c любой версией LibC, любой версией (...) и т.д.

.

Рекомендую сделать ссылку на репозитарий (пусть даже и локальный), откуда, в зависимости от платформы, будет браться нужный бинарник.

grot писал(а):Речь идет о статически-собранном бинарнике, у которого нет зависимистей на посторонние библиотеки !

Участвовал в обсуждении подобной темы в соседнем англ форуме, соображения свои высказал тут

Но я абсолютно далек от философии/концепций/подходов Линкус, а руководствовался только здравым смыслом и аналогией с Windows, раз ядро одно и то же, то обеспечь полную автономность (статически слинкуй все зависимости или имей их рядом с собой в папке программы .so и подгружай их динамически, не влияя при этом на остальную систему) и ты запустишься на любом линуксе.

Продолжаю испытания с
примером из Wiki по fpWeb, статически собранным :

SuSE 15.4 Leap 64-bit на ноутбуке -> OK
Debian 11 64-bit скачанный эталонный образ VDI для VirtualBox -> OK

Похоже, прежняя неудача с Debian 11 64-bit ( что стоял у хостинг-провайдера, закастомизированный в корягу ...) - не моя проблема,
а особенность данной инсталляции Debian 11 ...

grot писал(а):Похоже, прежняя неудача с Debian 11 64-bit ( что стоял у хостинг-провайдера, закастомизированный в корягу ...) - не моя проблема,
а особенность данной инсталляции Debian 11 ...

Это одна из проблем вирусов под Linux.
И, судя по:

grot писал(а):В Linux пусть это будет любой 64-bit дистрибутив с любой версией kernel , c любой версией LibC, любой версией (...) и т.д.

все-таки теперь ваша.

Кстати, тоже столкнулся с проблемой несовместимости бинарника. Полгода-год назад собранные в моей среде разработки бинарники запускались в Astra. После обновления - перестали, glibc в Astra слишком звездный. У меня rolling-release, так что просто признал для себя Astra падшей еще при рождении веткой, забил на ее поддержку. Единственный выход был - собирать бинарники в Astra, какое-то время так и делал, но там Lazarus тоже зазвездился (да и логотип Astra как бы намекает на врожденную отсталость генетического уровня), корячиться не стал.

Можно сделать совместимость со многими Linux-дистрибутивами, вплоть до совместимости 32-х битных и 64-х битных.

Это затратно, как по времени, так и по ресурсам. "Полностью кроссплатформенное" приложение будет содержать в себе много лишнего кода и библиотек.

Процесс:
Надо скомпилировать все зависимые библиотеки, которые используются, для 32-х и 64-х битных систем. Чтоб ни каких зависимостей от внешних библиотек не было.
Настроить приложение, чтоб оно определяло какая система запустила приложение (32-х битная или 64-х?).
Ну и предоставлять пользователю именно полный пакет, со всеми сопровождающими библиотеками.

Можно размер приложения уменьшить, и предоставлять два разных приложения для 32-х и 64-х битных систем. Но пользователь должен уметь разбираться какое из этих приложений ему нужно.

RRYTY писал(а):Кстати, тоже столкнулся с проблемой несовместимости бинарника. Полгода-год назад собранные в моей среде разработки бинарники запускались в Astra. После обновления - перестал, glibc в Astra слишком звездный. У меня rolling-release, так что просто признал для себя Astra падшей еще при рождении веткой, забил на ее поддержку. Единственный выход был - собирать бинарник в Astra, какое-то время так и делал, но там Lazarus тоже зазвездился (да и логотип Astra как бы намекает на врожденную отсталость генетического уровня), корячиться не стал.

Мне кажется достаточно было бы собрать с нужной версий glibc, если проблема была именно в этом, необязательно было собирать на Astra. Какую версию glibc он кстати просил?

Добавлено спустя 2 минуты 17 секунд:
Сама архитектура Linux подразумевает некий плюрализм, поэтому задачу нужно не так ставить. Можно просить пользователей установить нужные пакеты, если вдруг их не оказалось. К примеру, можно указать зависимости в deb пакетах

Ichthyander, код всё равно подогнать не получится. Или придётся использовать на "новых" системах "старый" код. А вообще, про зависимости надо было бы описать подробнее, тут не всем понятно будет про что ты вообще речь ведёшь.
Но в Linux наверно самое лучшее решение.

Seenkao писал(а):достаточно было бы собрать с нужной версий glibc, если проблема была именно в этом, необязательно было собирать на Astra. Какую версию glibc он кстати просил?

Нужная для Astra версия как раз в Astra. В среде разработки еще и зоопарк glibc держать не хочется. Нужна версия не старее 2.34. Может, это только начало, потом что-то еще захочет. Да и lazarus там 1.6, мне туда не откатиться. На этом этапе остановился.

Seenkao писал(а):Процесс:
Надо скомпилировать все зависимые библиотеки, которые используются, для 32-х и 64-х битных систем. Чтоб ни каких зависимостей от внешних библиотек не было.
Настроить приложение, чтоб оно определяло какая система запустила приложение (32-х битная или 64-х?).
Ну и предоставлять пользователю именно полный пакет, со всеми сопровождающими библиотеками.

Livecd со своей программой.

Да. Мерзотность Linux в этом вопросе зашкаливает. Но, любой линуксоид скажет, что это очень хорошо. Ведь очень хорошо, что нужно постоянно как в далеких 90-х годах пользоваться черным экраном и заучивать или списывать или копипастить дурацкие крокозябры ничего не значащие для нормального человека. 21 век, пользователь должен страдать)

stikriz11 писал(а):21 век, пользователь должен страдать)

Пользователь умер, это посмертные сокращения мышц: "Ах, непонятно! Ах, некрасиво! Ах, неизвестно!". Закапывайте уже. Пользователю псевдослучайная мазня в гермошлем, чтобы лежал и повизгивал. От пользователя - его ресурс, кто уж там чем богат. Six feet under.

grot писал(а):Хочу как в Windows

чтобы такое было на линуксе надо прогу писать на си и компилировать на той машине где будет запускаться, тогда гарантированно будет работать.
винда коммерческий продукт, обратная совместимость это ее фишка. но и то не всегда по написанное даже для 7 будет запускаться на 10 если использовались специфичные функции.

Я просто не в курсе. В Linux не слышали про позднее связывание? Ну, по имени найти метод и уже тога вызвать? В чем конкретно проблема so? Почему в windows dll можно вызвать от предыдущей версии, а Linux нет?