Соединение Статически с glibc и libstdc ++
Я пишу межплатформенное приложение, которое не является GNU совместимый GPL. Основная проблема, с которой я в настоящее время сталкиваюсь, состоит в том, что приложение связано динамично с glibc и libstdc ++, и почти каждое новое основное обновление библиотек не назад совместимо. Следовательно, случайные катастрофические отказы замечены в моем приложении.
Как обходное решение, я распределяю двоичные файлы своего приложения, скомпилированного в нескольких различных системах (с различными версиями среды выполнения C/C++). Но я хочу обойтись без этого. Таким образом, мой вопрос, сохраняя лицензирование и все в памяти, я могу связаться против glibc и libstdc ++ статически? Кроме того, это вызовет проблемы с rtld?
3 ответа
Вам не нужно.
Скопируйте исходные библиотеки, с которыми вы соединялись, в каталог (../lib в этом примере) в папке вашего приложения.
Например:
my_app_install_path
- .bin
- lib
- documentation
Переименуйте ваше приложение на что-то вроде app.bin. Замените ваше приложение на небольшой сценарий оболочки, который устанавливает переменную окружения LD_LIBRARY_PATH на путь к библиотеке (и объединяет предыдущее содержимое LD_LIBRARY_PATH, если оно есть). Теперь ld сможет найти динамические библиотеки, с которыми вы слинковались, и вам не нужно будет компилировать их статически в ваш исполняемый файл.
Не забывайте соблюдать LGPL, добавляя указанное авторство к библиотекам и указывая в документации, где можно загрузить исходный текст.
Я должен спросить, какого черта вы делаете с бедными библиотечными функциями?
У меня тоже есть кроссплатформенное программное обеспечение. Оно прекрасно работает на Linux-системах всех видов. Собирайте с самой старой версией программного обеспечения, которое вы хотите поддерживать. Библиотеки glibc и libstdc++ действительно очень обратно совместимы.
Я собирал на CentOS 4 и запускал его на RHEL 6 beta. Никаких проблем. Я могу собрать на стабильном Debian и запустить его на тестировании.
Правда, иногда у меня возникают проблемы с некоторыми библиотеками, если я пытаюсь собрать, скажем, на старом Debian и запустить его на CentOS 5.4. Обычно это связано с разными вариантами конфигурации дистрибутива, например, с выбором потоковой или непоточной обработки.
glibc находится под лицензией LGPL. В соответствии с разделом 6 LGPL 2.1 вы можете распространять свою программу, связанную с библиотекой, при условии, что вы соблюдаете один из пяти вариантов. Первый - предоставить исходный код библиотеки вместе с объектным кодом (исходный код не является обязательным, не требуется) вашей собственной программы, чтобы его можно было повторно связать с библиотекой. Вы также можете предоставить письменное предложение о том же. Ваш собственный код не обязательно должен соответствовать LGPL, и вам не нужно выпускать исходный код.
libstdc ++ находится под лицензией GPL, но с одним главным исключением . Вы можете просто распространять по лицензии по вашему выбору, не предоставляя исходный код для вашего собственного кода или libstdc ++. Единственное условие - вы компилируете нормально, например, без проприетарные модификации или плагины для GCC.
IANAL, и вам следует подумать о том, чтобы проконсультироваться с ним, если вам нужна настоящая юридическая консультация.