From: "Dmitry V. Levin" <ldv@altlinux.org> To: ALT Devel discussion list <devel@altlinux.ru> Subject: [devel] I: eliminating unneeded libtool library files Date: Mon, 1 Dec 2003 02:22:11 +0300 Message-ID: <20031130232211.GA1520@nomad.office.altlinux.org> (raw) [-- Attachment #1.1: Type: text/plain, Size: 4909 bytes --] Greetings! Тема сегодняшней лекции - о пользе и вреде .la-файлов. :) Как вы наверняка уже знаете (а если не знаете, то info libtool), libtool хранит вспомогательную информацию о библиотеках, с которыми работает, в т.н. libtool-файлах (они же .la-файлы). Эту информацию libtool использует в процессе изготовления и использования библиотек. Таким образом, .la-файлы жизненно необходимы libtool'у для корректной сборки пакета. После установки файлов из пакета в систему libtool, как правило, не используется во время работы собранных им библиотек и программ, поэтому вспомогательные .la-файлы для них не нужны. Исключение составляет лишь загрузка plugin'ов с помощью средств библиотеки ltdl. Тем не менее авторы libtool предлагают устанавливать эти .la-файлы. Зачем? Тут самое время вспомнить, что GNU libtool проектировался таким образом, чтобы реализовать поддержку как можно большего числа операционных систем, в том числе и тех, которые не поддерживают работу с разделяемыми библиотеками или поддерживают её в неполной (по сравнению с GNU/Linux) мере. Для многих таких платформ информация о зависимостях между библиотеками не может быть записана в самих библиотеках. Поэтому libtool сохраняет информацию о зависимостях в .la-файлах, сопровождающих устанавливаемые библиотеки, и использует эту информацию при сборке других библиотек и программ. К сожалению, libtool никогда не имел и сейчас не содержит оптимальной поддержки всех возможностей, которые предоставляет GNU/Linux. Поэтому при наличии "сопровождающих" .la-файлов в системе libtool поступает так же, как и в других системах, а именно линкует все целевые объекты со всеми библиотеками, от которых зависят непосредственно используемые библиотеки. Таким образом, косвенные зависимости превращаются в прямые зависимости, т.е. программы и библиотеки оказываются слинкованными с библиотеками, которые они непосредственно не используют. Наглядный и простой пример из базовой системы: Есть apt-rpm (далее просто apt), который использует библиотеку librpm. В свою очередь librpm (а именно librpmdb) использует библиотеку libdbX для работы с базой данных пакетов rpm (/var/lib/rpm), причём для rpm-4.0.4 у нас X == 4.0. Сам apt никакой libdb не использует, но благодаря libtool'у и /usr/lib/librpm*.la он линкуется не только с librpm, но и с libdb4.0. Теперь представьте себе, что rpm-4.0.4 перешёл с libdb4.0 на libdb4.1. Поскольку смены API в librpm не произошло, клиенты librpm не были пересобраны. В момент запуска apt'а загружаются сразу две libdb: libdb4.0, с которой был собран apt, и libdb4.1, с которой был собран librpm. Хорошо ещё, что apt не пишет в базу данных rpm, так что последняя, скорее всего, уцелеет. Этих (и других похожих) неприятностей можно было бы избежать, если бы можно было решить одну из двух задач: 1. Исправить libtool, чтобы он нормально поддерживал link_all_deplibs=no, т.е. не линковал то, что не требуется. К сожалению, решение этой задачи ничего не даст в виду специфического дизайна GNU libtool: дело в том, что почти каждый пакет с исходным текстом, использующим для сборки libtool, содержит свою копию libtool, и для сборки будет использована именно эта копия, а не системный libtool. Для того, чтобы заменить libtool на системный цивилизованным образом, необходимо использовать aclocal и autoconf, что не всегда возможно. 2. Убрать все вредные .la-файлы из системы. Для решения этой задачи достаточно один раз пересобрать содержащие вредные .la-файлы пакеты и проследить, чтобы они туда случайно не вернулись. По очевидным причинам я выбрал второй вариант. В /usr/lib/rpm/brp-cleanup пакета rpm-build >= 4.0.4-alt28 добавлен код, который удаляет все файлы, имена которых заканчиваются на .la, из каталогов /lib, /usr/lib и /usr/X11R6/lib. Одновременно в пакет sisyphus >= 0.5.4-alt1 была добавлена проверка на наличие таких файлов в пакете. Порядок пересборки тоже важен. Начинать нужно с тех бинарных пакетов, которые содержат .la-файлы, в которых нет ссылок на другие .la-файлы. Только в этом случае при пересборке произойдёт очистка от ненужных зависимостей. На данный момент в Сизифе всего 500 бинарных пакетов, содержащих разные .la-файлы, в том числе и те самые вредные .la-файлы, которые сопровождают библиотеки. Помимо них, есть ещё много .la-файлов, сопровождающих plugin'ы. Иногда такие .la-файлы используются для динамической загрузки plugin'ов с помощью средств библиотеки ltdl. Во всех остальных случаях от них нет ни пользы, ни вреда. В окончание я привожу список из 50 бинарных пакетов, которые надо пересобрать в первую очередь, ибо непересборка этих пакетов не даёт возможности пересобрать ещё примерно 240 других бинарных пакетов. Я прошу всех разработчиков в офисе ALT Linux незамедлительно собрать свои пакеты из этого списка, а всех разработчиков вне офиса, кто не может этого сделать, так же быстро написать об этом с тем, чтобы мы могли сделать это за вас. -- ldv [-- Attachment #1.2: first --] [-- Type: text/plain, Size: 734 bytes --] freetype2-devel freetype-devel gift-devel guile14 guile16 id3lib-devel imlib-devel libaspell-devel libbluez-devel libbonobo-devel libcdf-devel libcurl-devel libeel2-devel libfaad-devel libflac-devel libfreetds-devel libfribidi-devel libgal-devel libgii-devel libgmp-devel libgnome-desktop-devel libgnome-panel-devel libgpgme-devel libhdf-devel libieee1284-devel libldap-devel liblinc-devel libmad-devel libmdbtools-devel libmetacity-devel libmm-devel libnessus-devel libnetcdf-devel libogg-devel libopenobex-devel libpcsclite-devel libpilot-link-devel librte-devel libsasl2-devel libSDL-devel libsigc++1.2-devel libsim libsim-qt libunixODBC-devel libusb-devel libxfce4util-devel libxmms-devel libxosd-devel ORBit-devel plptools-devel [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2003-11-30 23:22 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-11-30 23:22 Dmitry V. Levin [this message] 2003-12-01 10:23 ` Vitaly Lipatov 2003-12-01 11:27 ` [devel] " Alexey Tourbin 2003-12-01 12:29 ` vserge 2003-12-02 10:20 ` [devel] " Dmitry V. Levin 2003-12-04 20:42 ` [devel] " Michael Shigorin 2003-12-04 20:50 ` Michael Shigorin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20031130232211.GA1520@nomad.office.altlinux.org \ --to=ldv@altlinux.org \ --cc=devel@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git