Differences

This shows you the differences between two versions of the page.

--- etc:users:jcmvbkbc:lib_coexistence_policy [2007/12/19 21:41] – jcmvbkbc
+++ etc:users:jcmvbkbc:lib_coexistence_policy [2016/08/08 20:53] (current) – ↷ Page moved from users:jcmvbkbc:lib_coexistence_policy to etc:users:jcmvbkbc:lib_coexistence_policy kel
@@ Line 34: / Line 34: @@
  Если исполняемые файлы находятся в разделяемых каталогах (/bin, /usr/bin) их имена должны включать в себя тэг, аналогичный имени пакета. В остальных случаях смысла в этом нет.
  Если требуется вызов программ из разных пакетов по одному имени, следует использовать alternatives. Однако, возникает сложность с размещением символьной ссылки, если исходный пакет не рассчитан на alternatives. Так, например, в случае gcc (2.95) и gcc-3.4.5-mcbc, пришлось делать ссылку /bin/gcc.
 ==== Пути поиска динамических библиотек и ld.so.conf ====
- ld.so.conf не модифицировать. В ld.so.conf.d не писать. ldconfig в post и postun не вызывать так. Однако, собирать всю означенную информацию в симметричном месте, соответсвующем конфигурации (/etc/altenvironment/3.4.5-mcbc).
+ Библиотеки помещать в отдельное поддерево с тэгом в имени (/usr/lib-3.4.5-mcbc). Имена библиотек и SONAME не менять. Соответствующий макрос добавлен в rpmmacros.
+ ld.so.conf не модифицировать. В ld.so.conf.d не писать. ldconfig в post и postun не вызывать так. Однако, собирать всю означенную информацию в симметричном месте, соответсвующем конфигурации (/etc/altenvironment/3.4.5-mcbc).
  Вызывать ldconfig с этой информацией, но без обновления ld.so.cache. Здесь -- очень странное место: я бы предпочёл обновлять свой, сторонний кэш, а потом подсовывать его ld.so при запуске сторонней программы. Первая половина этого процесса (другой кэш) возможна, вторая -- нет ): Почему -- загадка.
- Далее, DT_RUNPATH vs. LD_LIBRARY_PATH. Соблазнительно использовать первое. Однако на эти грабли мы уже наступали -- получается очень жесткая, неконфигурируемая структура. Одного моего опыта, конечно, мало. Поэтому ссылаюсь на мнение разработчиков Fedora: [[http://fedoraproject.org/wiki/Packaging/Guidelines#head-a1dfb5f46bf4098841e31a75d833e6e1b3e72544|Beware of Rpath]].
+ Далее, DT_RUNPATH vs. LD_LIBRARY_PATH. Соблазнительно использовать первое. Однако на эти грабли мы уже наступали -- получается очень жесткая, неконфигурируемая структура. Одного моего опыта, конечно, мало. Поэтому ссылаюсь на мнение разработчиков Fedora: [[http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath|Beware of Rpath]].
  Итак, LD_LIBRARY_PATH. Устанавливается скриптом, сейчас он называется /usr/bin/run-3.4.5-mcbc. Объединяет все пути найденные в /etc/altenvironment/3.4.5-mcbc/*.conf. Если этот скрипт запускать по имени "$0", то он после установки LD_LIBRARY_PATH запускает программу "$0-3.4.5-mcbc". Соответственно, скрипт /usr/bin/link-3.4.5-mcbc переименовывает переданные ему в качестве параметров бинарники в *-3.4.5-mcbc и создает на их месте символьную ссылку на run-3.4.5-mcbc.
+ Вероятно, имеет смысл добавить что-ньть типа ldconfig-3.4.5-mcbc, обновляющий символьные ссылки по файлам из /etc/altenvironment/*/*.conf
+{{tag>МСВС RFC}}
+~~DISCUSSION~~