Связывание статически с glibc и libstdС++

Я пишу кросс-платформенное приложение, которое не совместимо с GNU GPL. Основная проблема, с которой я столкнулся сейчас, заключается в том, что приложение динамически связано с glibc и libstdС++, и почти каждое новое крупное обновление для библиотек не обратно совместимо. Следовательно, случайные сбои отображаются в моем приложении.

В качестве обходного пути я распространяю двоичные файлы моего приложения, скомпилированные в нескольких разных системах (с разными версиями C/С++). Но я хочу обойтись без этого. Поэтому мой вопрос заключается в том, чтобы сохранить лицензию и все в виду, могу ли я связать с glibc и libstdС++ статически? Также это вызовет проблемы с rtld?

Ответ 1

Задание опции -static-libgcc компоновщику приведет к ее связыванию со статической версией библиотеки C, если она доступна в системе. В противном случае он игнорируется.

Ответ 2

Вам не нужно.

Скопируйте исходные библиотеки, с которыми вы связаны, в каталог (../lib в этом примере) в папке вашего приложения.

Как

my_app_install_path

.bin
Lib
документация

Переименуйте приложение для чего-то вроде app.bin. Замените приложение на небольшую оболочку script, которая устанавливает переменную окружения LD_LIBRARY_PATH в путь библиотеки (и объединяет предыдущее содержимое LD_LIBRARY_PATH, если оно есть). Теперь ld должен иметь возможность находить динамические библиотеки, с которыми вы связаны, и вам не нужно их статически ставить на ваш исполняемый файл.

Помните, что LGPL добавляет данную атрибуцию в библиотеки и указывает на документацию, в которую можно загрузить исходный код.

Ответ 3

glibc находится под LGPL. В разделе 6. LGPL 2.1 вы можете распространять свою программу, связанную с библиотекой, если вы выполняете один из пяти вариантов. Во-первых, предоставить исходный код библиотеки, а также объектный код (источник необязателен, не требуется) вашей собственной программы, поэтому его можно перенаправить с библиотекой. Вы также можете предоставить письменное предложение того же самого. Ваш собственный код не должен находиться под LGPL, и вам не нужно выделять источник.

libstdС++ находится под GPL, но с основным исключением. Вы можете просто распределить по лицензии по вашему выбору, не предоставляя исходный код для своего собственного кода или libstdС++. Единственное условие заключается в том, что вы обычно компилируете, без, например, внесенные изменения или плагины в GCC.

IANAL, и вам следует подумать об этом, если вам нужна настоящая юридическая консультация.

Ответ 4

Я должен задать вопрос, что вы делаете с плохими библиотечными функциями?

У меня также есть кросс-платформенное программное обеспечение. Он отлично работает на всех Linux-системах. Постройте с помощью самой старой версии программного обеспечения, которую вы хотите поддержать. Библиотеки glibc и libstdС++ действительно очень обратная совместимость.

Я построил на CentOS 4 и запустил его на бета-версии RHEL 6. Нет проблем. Я могу построить стабильный Debian и запустить его при тестировании.

Теперь у меня иногда возникают проблемы с некоторыми библиотеками, если я пытаюсь построить, скажем, старый Debian и пытаюсь запустить его на CentOS 5.4. Это обычно происходит из-за выбора конфигурации распределения, которые различны, например, для выбора потока или без потоковой передачи.