На главную -> MyLDP -> Программирование и алгоритмические языки

---

Ulrich Drepper "Как писать разделяемые библиотеки"
Назад	Оглавление	Вперед

---

3.4. Реструктурирование экспорта

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

В разделе 2.2 были представлены имеющиеся для этого механизмы. Теперь, когда была преложена техника контроля версий, мы можем немного продолжить это обсуждение. В качестве одной из возможностей ограничения экспорта было предложено использовать таблицы символов. В идеале таблицы символов должны всегда использоваться в качестве дополнение к другим выбранным методам. Дело в том, что это позволяет ассоциировать имена версий с интерфейсами, которые в свою очередь, позднее позволят вносить несовместимые изменения и не нарушать при этом интерфейс ABI. В примере файла таблицы символов, приведенном в разделе 2.2.5, имя версии не указывается. Вариант с определением имени версии будет выглядеть следующим образом:

VERS_1.0 {
	global: index;
	local: *;

В этом примере VERS 1.0 является произвольно выбранным именем версии. Что касается статического и динамического компоновщика, то имена версий просто являются строками. Но для удобства сопровождения желательно, чтобы в выбранном имени присутствовало имя пакета и номер версии. Например, для проекта библиотеки GNU C выбираются имена GLIBC 2.0, GLIBC 2.1 и т.д.

---

Предыдущий раздел:		Следующий раздел:
Назад	Оглавление	Вперед

---

---