Наличие недавно скомпилированного C++ .so для запуска в старых системах, если не отображаются стандартные символы.

Моя цель - использовать последние функции C++, такие как интеллектуальные указатели (по крайней мере, std::shared_ptr) для библиотеки linux C++, которая должна работать в нескольких дистрибутивах (очевидно, перекомпилируя ее для каждой платформы). Самый старый gcc, на который я ориентируюсь, — 4.4.x, так как мне нужно поддерживать RHEL6. Кажется, умные указатели поддерживаются для простой программы, например

#include <iostream>
#include <memory>

int main()
{
    std::shared_ptr<int> aa;
    return 0;
}

Моя библиотека будет предоставлять C API (extern), я не использую исключения и типы C++ в API. Я статически связываю libstdc++ и libgcc и помечаю все символы как локальные, кроме экспортируемых API.

У меня теперь другой вопрос: в ситуации выше будет ли библиотека, скомпилированная с более новым gcc (например, 5.0 или даже 6.0), работать в более старой системе, такой как RHEL6 с установленным по умолчанию gcc 4.4.x надежно?

Теоретически, использование более поздних функций С++, но не раскрытие каких-либо из них в символах или API, должно работать, но я не очень уверен, и я бы предпочел спросить.


gcc c++ linux abi shared-libraries
person Dean    schedule 16.07.2018    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Да.

На самом деле, Red Hat опубликовала запись в блоге о вашей ситуации:

Пользователи, которые зависят от сторонних библиотек или интерфейсов плагинов, которые все еще используют старый ABI, могут создавать свой код с помощью -D_GLIBCXX_USE_CXX11_ABI=0, и все должно работать нормально. В большинстве случаев будет очевидно, когда этот флаг необходим, из-за ошибок компоновщика, жалующихся на неразрешенные символы, включающие __cxx11.

[] План изменения ABI [C++11] заключался в том, чтобы оставить soname (и существующий двоичный интерфейс) в покое и выразить новый ABI, используя другие искаженные имена.

Поскольку вы компилируете с помощью libstdc++ статически, все приложения будут работать надежно или не будут компоноваться. Когда это произойдет, измените флаги компиляции, чтобы добавить _GLIBCXX_USE_CXX11_ABI=0.

Подводя итог, вы не должны заботиться об изменениях API, только об изменениях ABI. И на этот раз команда GNU все сделала правильно!

person YSC    schedule 16.07.2018
comment
Ничего общего с макросом _GLIBCXX_USE_CXX11_ABI нет. - person Yuki; 16.07.2018
comment
Этот макрос только про сборку старого хлама с новым libstdc++ и он не хочет выносить новый libstdc++ на исполняющие машины, как я понял. - person Yuki; 16.07.2018
comment
Я просто хочу, чтобы мой .so надежно выполнялся как на новых, так и на старых машинах (начиная с вышеупомянутой RHEL6 как самой старой архитектуры, которую мне нужно поддерживать, остальные варьируются от Ubuntu16-18 до CentOS7). Если я смогу сделать это, используя новые функции C++, тем лучше. - person Dean; 16.07.2018
comment
@Dean Если вы связываетесь статически, то это не имеет значения, у вас уже есть все внутри, если нет, то у вас есть сборка libstdc ++, которую вы создаете, для каждой платформы, на которой вы планируете ее запускать. Кстати, вам нужно иметь сборочную машину одного и того же дистрибутива для каждого типа, который у вас есть в производстве. - person Yuki; 16.07.2018
comment
@Yuki Я больше имел в виду конфликты символов, если пользовательское приложение, которое загружает мою библиотеку .so, также использует другую версию стандартной библиотеки. Не уверен, что тогда произойдет, и поэтому я принимаю все символы «отметить как локальные», кроме мер предосторожности API. - person Dean; 17.07.2018

arrow_upward
1
arrow_downward

Предполагая, что вы компилируете и запускаете свою библиотеку в одном и том же дистрибутиве, т. е. libc, libpthread и т. д. Тогда она должна полностью работать, единственное, о чем нужно заботиться, это libgcc (библиотека времени выполнения gcc). Он может вести себя по-разному, если версии разные, например 1.1 и 1.2. Поэтому убедитесь, что вы используете те же версии, т.е. gcc-5/6 не приносил никаких новых версий libgcc, о чем я не знаю, и я склонен думать, что это версия 1 везде, так что не беспокойтесь.

person Yuki    schedule 16.07.2018