ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Damir Shayhutdinov <damir@altlinux.org>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] [FAQ] линковка плагинов
Date: Thu, 16 Dec 2010 11:33:09 +0300
Message-ID: <AANLkTikhPYhFai7tYaw2rqxndaOEnVMWCqW8qWbKZunu@mail.gmail.com> (raw)
In-Reply-To: <1292485808.8611.2@ildar.innovations.kz>

> Итак, имеем:
> 1. библиотеку в %_libdir/ , которую используют многие программы.
> 2. её плагины (или модули, дело не в названии), которые располагаются в
> другой папке, например %_libdir/lib%name/
>
> У нас принято считать, что, если это возможно (а это примерно 95% случаев),
> нужно линковать плагины с библиотекой, получив на выходе в идеале
> не-недолинкованные плагины.
> Давайте посмотрим на это с разных сторон:
> 1. В рамках дистрибутива это, несомненно хорошо. Такого рода связи позволяют
> отслеживать зависимости, что является одним из столпов нашего репозитария.
> 2. Однако бывают и другие варианты использования, включающие в себя
> чужеродный софт в системе. Получается, что возможны случаи, когда чужеродная
> программа, которая несёт свою версию библиотеки, поднимет плагин, который
> слинкован с нашей библиотекой. Итого: пришли к двум одинаковым библиотекам в
> адр. пространстве одной программы. А это плохо.

Если у "своей" версии библиотека liblua динамическая, и имеет тот же
soname, то не будет две одинаковые библиотеки в одном адресном
пространстве, все счастливы. Проблемы будут только если liblua
вкомпилена статически, а это в нашем дистрибутиве не поощряется.

> Итак вопрос: нужно ли линковать плагины с основной библиотекой, или
> оставлять их недолинкованными?

Конкретно в случае lua, апстрим рекомендует именно статическую сборку
с liblua на x86, из соображений производительности.  Результатов
тестов, показывающих преимущество статической сборки перед
динамической, я не видел, поэтому что они называют significant
performance loss, я не знаю. Может 2%, может 20%. С точки зрения
безопасности лучше собирать все динамически, а в таком случае лучше
долинковывать, чтобы была зависимость на версии символов и soname.
Желающим производительности рекомендовать использовать x86_64 :)

      reply	other threads:[~2010-12-16  8:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-16  7:50 Ildar Mulyukov
2010-12-16  8:33 ` Damir Shayhutdinov [this message]

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=AANLkTikhPYhFai7tYaw2rqxndaOEnVMWCqW8qWbKZunu@mail.gmail.com \
    --to=damir@altlinux.org \
    --cc=devel@lists.altlinux.org \
    /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