Православно распространить libGLEW.so

Так может и для libGLEW пакет проще какой-то установить

наверное версия libGLEW на арче выше чем на убунте, поэтому ругается.

В чем проблема собрать на убунте?

Да банально лень заводить убунту, если ее можно не заводить. Да и если я скомпиляю на убунте, взлетит ли этот экзешник на другой версии убунты? Да хоть бы на той же самой, скажем после обновления? Ведь если прога установлена не через пакетный менеджер, то обновлятор может и старые пакеты снести за ненадобностью...

Вообще я имел ввиду сделать пакет, это самый надежный способ. А как ты планировал устанавливать libalut-dev на компы пользователей? По поводу закидывания пакетов, может прокатить, пока что-то еще не отвалится. Например какая-то либа, которую до этого линковщик находил, апнет версию. Хотя если это игра, то по идее зависимостей не много и шанс минимальный.

Ага, ну общую картину я понял. Спасибо за разъяснения.

Да и если я скомпиляю на убунте, взлетит ли этот экзешник на другой версии убунты?

Во-первых, не «экзешник», а elf.
Во-вторых, взлетит при условии одинаковой libc или чем ты ее там компилил.

Статическая линковка?

если православно для ubuntu, то надо опакетить для хотя бы для последних двух LTS версий.

Этот пакет поставь.

Совсем православно ­— это PPA.

flatpack.

Спасибо, попробую.

Всем спасибо за варианты.

Посмотри как я сделал это здесь: https://yadi.sk/d/yw8Zt-VmpyVpL и здесь: https://yadi.sk/d/VU8tPelkZrBd7

При компоновке идет привязка к той версии библиотек, что есть в системе, где идет сборка. Первый путь - собирать на старом дистрибутиве. Второй - использовать chroot, с ним можно сделать образ старой системы прямо на новой. Так, кстати, работает iOS SDK и Android NDK - они таскают образы ОС определённых версий.

Многие библиотеки вроде boost и stl можно собрать статически. Но не все - библиотеки из mesa могут подменяться проприетарными дровами, а их версия должна выбираться пользователем, чтобы тот не остался без поддержки видеокарты.

Автор, ты ещё здесь? Посмотри мои ссылки. Да, это Яндекс.Диск, ну и что?

Первая ссылка - это PCSX2 2017 года, собранный в линуксе 2007-го. Я там откатил несколько коммитов, смыслом которых было просто использование более новых вызовов GTK2, которые делают всё то же самое, что и старые. Также я в самой билд-ферме установил GCC 4.8 и новые заголовочные файлы OpenGL. libglew я распространяю вместе с программой. Посмотри, как именно я это сделал.

По второй ссылке ничего интересного, за исключением того, что там два варианта одной программы: 32-бит и 64-бит. Я взял этот скрипт запуска в игре World of Goo в 2010 году, когда была вторая волна появления игр для Linux.

Во-первых, не «экзешник», а elf.

Отставить тупняк.
ELF — Executable and Linkable Format (в прошлом — Extensible Linking Format).

EXEcutable, стало быть «экзешник».

Да я их сразу посмотрел. Я чет не пойму куда там смотреть, libGLEW.1.13 - оно? Так я ж и закинул libGLEW.2.1 в папку с прогой. Второй посмотрел, но я только на 64 бита конпеляю, поэтому тут проблем нету.

Так, стопэ, а для чего использовать gcc 4.8? Я знаю - оно на убунте стоит, но как это связано, если нужно целое окружение, но понимаю. Я так то с самого начала на 7.2 сижу, с++17 гоняю понемногу, как быть? Объясните как тапку.

Образ старой системы - это как? Это вся бубунта что ли? И если мне нужно конпелять для трех бубунт, мне нужно три чрута?

И я вот что хочу уточнить: мой libGLEW.2.1 на убунте то ведь и крашнуться мог если бы эта библиотека делала системные вызовы которые есть на арче и нет на бубунте (из-за разных версий ядра)? Или она может еще другие динамически библиотеки дергать, которых может не быть? И как я понимаю, хоть риск этого и минимален, то лучше всего скомпилировать на бубунте?

> Да я их сразу посмотрел. Я чет не пойму куда там смотреть

Скрипт run_game.sh, который «подцепляет» директорию lib.

> Так, стопэ, а для чего использовать gcc 4.8?

Компилировал давно просто.

Увидел, понял. Хорошо, буду знать, спасибо.

> И я вот что хочу уточнить: мой libGLEW.2.1 на убунте то ведь и крашнуться мог если бы эта библиотека делала системные вызовы которые есть на арче и нет на бубунте (из-за разных версий ядра)?

Нет. В ядре Linux соблюдается железобетонная обратная совместимость. Совместимость для программ пользователя, но не для драйверов.

Как-то раз Линус Торвальдс отпиз жёстко наорал орально на одного программиста ядра, который эту самую совместимость сломал. В тот момент самым популярным DE было KDE (GNOME вышел на 1 место в 2006). Была (и есть) такая утилита kdesu, которая позволяет запустить графическое приложение от рута. В то время su и sudo так не могли, и считалось правильным запускать от sudo только текстовые проги, а при помощи kdesu - графические.

В ядре исправили какой-то «косяк», а потом обнаружили, что сломался kdesu. Автор патча в ядро, который всё сломал, написал кдешникам, чтобы они адаптировали прогу для нового ядра Linux. Но тут приходит Линус Торвальдс и в своей известной манере объясняет, что обратную совместимость ломать нельзя. И что тот «косяк» нужно исправить каким-нибудь другим способом.

Автор патча, сломавшего совместимость, начал переубеждать Торвальдса. Мол, пользователи ничего не заметят. Как правило, они обновляют ядро и DE синхронно, когда устанавливают новую версию дистрибутива. В ответ Линус обматерил его трёхэтажным матом. Именно тогда прозвучала знаменитая фраза «пользователя не волнует»

Короче, не парься. при обновлении ядра Linux, никакое пользовательское ПО не перестанет работать. Я вот даже проводил эксперимент. А вместо kdesu в современной Ubuntu можно использовать gksudo.

Да, а я где-то слышал уже про это кипиш. Но у меня ведь немного другое - я не с убунты на рач тащу либу старую, я с рача на бубунту!