Как избежать конфликтов стандартных библиотек в Unix - PullRequest
Новая
       53

Как избежать конфликтов стандартных библиотек в Unix

0 голосов
/ 25 июня 2018

У меня есть объект совместно используемой библиотеки (so), который предоставляет C API (extern "C"). Он не использует C ++ в API и не генерирует исключения. Внутренне он использует C ++, особенно std::map и другие контейнеры, а также некоторые тривиальные шаблоны.

Моя цель - предоставить эту библиотеку любой программе в Unix (я компилирую несколько версий для каждого целевого дистрибутива Linux) без проблем со стандартными символами библиотеки в программе загрузчика (т.е. в программе, которая загружает мою библиотеку с * 1005). * должен работать правильно, даже если он был скомпилирован с другой версией стандартной библиотеки).

Вот что я сделал, прочитав:

  1. Статически связаны как libstdc ++, так и libgcc

  2. использовал скрипт компоновщика для маркировки всех локальных символов, кроме C-ABI, экспортированных из API 

    linker_script.lds
{
  global: my_api_func;
  local: *;
}

g++ shared.cpp -Wl,--version-script=vs.lds -fPIC -static-libstdc++ -static-libgcc -shared -o libshared.so

Мой вопрос на данный момент: будет ли этого достаточно, чтобы я продолжал использовать C ++ для себя и избегал всех конфликтов, если загружающая программа использует другую (основную / вспомогательную / совершенно другую) версию стандартной библиотеки? Что если я использую C ++ 14 или что-то еще более новое и следую вышеупомянутой процедуре?

1 Ответ

0 голосов
/ 25 июня 2018

Мой вопрос на данный момент: будет ли этого достаточно, чтобы я продолжал использовать C ++ внутри себя и избегал всех конфликтов, если загружающая программа использует другую (основную / вспомогательную / совершенно другую) версию стандартной библиотеки?

Этого должно быть достаточно. Но проверьте:

  1. что нет неожиданных неопределенных символов из std:: с nm -C --undefined-only <my.so>.
  2. Что ваша библиотека не экспортирует никаких символов из стандартной библиотеки C ++ с nm -C --defined-only --extern-only <my.so>. И любые символы вы не ожидаете его экспортировать.
  3. Что нет неожиданных необходимых общих библиотек с readelf -d <my.so>.

Что, если я использую C ++ 14 или что-то еще более новое и следую вышеупомянутой процедуре?

Пока вы проверяете, какие символы использует и экспортирует ваша библиотека, этот метод будет работать.

...