Ограничение символов локальной областью для исполняемого файла Linux

Question

Может кто-нибудь предложить, каким образом мы можем ограничить экспорт наших символов в глобальную таблицу символов?

Заранее спасибо

---

Привет

Спасибо, что ответили ...

На самом деле у меня есть исполняемый файл, который статически связан со сторонней библиотекой, скажем, "ver1.a", а также использует сторонний файл ".so", который снова связан с той же библиотекой, но другой версией, скажем, "ver2.a" , Проблема в том, что реализация обеих этих версий различна. В начале, когда исполняемый файл загружен, символы из «ver1.a» будут экспортированы в глобальную таблицу символов. Теперь всякий раз, когда загружается «.so», он пытается ссылаться на символы из ver2.a, в конечном итоге он ссылается на символы из «ver1.a», которые были ранее загружены. Таким образом, происходит сбой нашего двоичного файла.

мы подумали о решении, которое заключается в том, что мы не будем экспортировать символы для исполняемого файла в глобальную таблицу символов, таким образом, когда «.so» загружается и пытается использовать символы из ver2.a, он не найдет его в глобальной таблице символов и будет использовать свои собственные символы, т.е. символы из ver2.a

Я не могу найти способ ограничить экспорт символов в глобальную таблицу символов. Я попытался с --version-script и retain-symbol-file, но это не сработало. Для опции -fvisibility = hidden она выдает ошибку, что «-f опция может использоваться только с -shared». Так что, я думаю, это тоже, что и --version-script, работает только для разделяемых библиотек, а не для исполняемых двоичных файлов.

код на c ++, OS-Linux, gcc версия-3.2. Может оказаться невозможным перекомпилировать какие-либо сторонние библиотеки и ".so". Таким образом, опция перекомпиляции файла so с флагом bsymbolic исключена.

Любая помощь будет оценена.

Answer 1

Потяните в стороннюю библиотеку с помощью dlopen.

Вы можете избежать этого, создав собственную разделяемую библиотеку, которая скрывает все сторонние символы и предоставляет им только ваш собственный API, но если все остальное терпит неудачу, dlopen дает вам полный контроль.

Answer 2

У меня возникла похожая проблема / вопрос: Segfault в библиотеке плагинов C ++ с дублирующимися символами

Если вы можете перестроить стороннюю библиотеку, вы можете попробовать добавить флаг компоновщика -Bsymbolic (флаг для gcc / g ++ будет -Wl,-Bsymbolic). Это может решить вашу проблему. Все зависит от организации вашего кода и прочего, так как есть предостережения по его использованию:
http://www.technovelty.org/code/c/bsymbolic.html
http://software.intel.com/en-us/articles/performance-tools-for-software-developers-bsymbolic-can-cause-dangerous-side-effects/

Если вы не можете восстановить его, по первой ссылке:

На самом деле, единственное, что -символическое флаг делает при построении общего библиотека добавить флаг в динамическом раздел двоичного файла называется DT_SYMBOLIC.

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

Answer 3

Самое простое решение - переименовать символы (путем изменения исходного кода) в вашем исполняемом файле, чтобы они не конфликтовали с разделяемой библиотекой.

Следующая простейшая вещь - локализовать «проблемные» символы с помощью 'objcopy -L problem_symbol'.

Наконец, если вы не связываетесь напрямую со сторонней библиотекой (но вместо этого устанавливаете ее, как подсказывает bmargulies), и ни одна из ваших других общих библиотек не использует определение символа "проблема" и вы не связываетесь с -rdynamic или одним из его эквивалентов, тогда символ не должен экспортироваться в таблицу символов dynamic исполняемого файла, и, следовательно, вы не должны иметь конфликт.

Примечание: 'nm a.out' будет все еще , покажет символ как глобально определенный, но это не имеет значения для динамического связывания. Вы хотите посмотреть на динамическую таблицу символов a.out с 'nm -D a.out'.