ALT Linux Team development discussions
 help / color / mirror / Atom feed
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 --]

             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