поводу распространения программы, пакетирования. Конкретно интересует Linux. Сначала ориентировался на AppImage, но целевые системы на базе Debian, поэтому в идеале хотелось, чтобы это был deb пакет. Но при этом хотелось бы таскать все зависимости с собой, как в AppImage, в том числе libstdc++ и libgcc_s (так как собирается всё на свеженьком GCC, но на старом glibc). Идея такая: положить все либы в /usr/lib/<appname>/, основной executable файл положить туда же, а в /usr/bin/ положить скрипт, который будет выставлять нужный LD_LIBRARY_PATH и вызывать executable файл программы (такой способ использует, например, ardour, как описано здесь https://stackoverflow.com/a/14500152). Какие есть подводные камни? Больше всего интересует, не сломаю ли другие программы?
/opt/<app>/bin/<app> — это скрипт, который как и сказали, выставляет LD_LIBRARY_PATH. Сам бинарь переименован в <app>-bin.
Не Open Source, коммерческое. GUI. Мы собираем на какой-то старой Ubuntu. То ли 14.04, то ли 16.04, сейчас не скажу. В общем, с glibc проблем нет (если я правильно понимаю, этого и пытаются избежать, собираясь на старой системе).
Красота. Звучит, как то, что нужно. Спасибо, что поделились своим опытом.
Ну вот для работы WebEngine это необходимо. А в чём конкретно проблема? 😊
А, я вот как раз WebEngine выпиливаю. Но так-то другие executable файлы у нас имеются, и запускать их нужно, так что наследование LD_LIBRARY_PATH в этом плане хорошо. Но программа может запускать сторонние приложения на компьютере (какой-нибудь текстовый редактор по выбору пользователя для редактирования файла), что в теории может привести к каким-нибудь конфликтам либ. В принципе, я так понимаю, в этом случае нужно просто из environment перед запуском выпилить LD_LIBRARY_PATH.
На 6 одна, на 7 другая
Детали, детали. Собираюсь в докере с какой-то старой убунтой, где glibc относительно старый (2.23). На целевой системе 2.24, если не ошибаюсь. Соответственно, старше 2.24 никак нельзя. Приложение коммерческое, линковаться статически тоже нельзя. В докер образе из исходников собран новый GCC (то ли 10, то ли 11, не помню). Хотелось бы использовать как можно новее всегда, периодически обновляться. На целевой системе, соответсвенно, нет ни нового компилятора, ни новой стд либы, поэтому планируется libstdlibc++ и libgcc_s закинуть к программе. Я проверял, это работает. Судя по https://distrowatch.com/table.php?distribution=centos, по версии glibc, 7-ая версия ещё подходит, а вот 8-ая уже нет.
Обсуждают сегодня