From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 4 Feb 2004 00:35:22 +0300 From: Alexey Tourbin To: devel@altlinux.ru Message-ID: <20040203213522.GE23713@solemn.turbinal.org> Mail-Followup-To: devel@altlinux.ru Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ryJZkp9/svQ58syV" Content-Disposition: inline Subject: [devel] libtool: la_LIBADD vs noinst_LIBRARIES X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 21:36:12 -0000 Archived-At: List-Archive: List-Post: --ryJZkp9/svQ58syV Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit Здравствуйте. Для тех, кто не в курсе, краткая справка: libtool -- это wrapper для компилятора и линкера для упрощенного создания библиотек. Псевдо-библиотека libtool имеет суффикс .la (пресловутые .la files). Псевдо-библиотеке соответствуют статическая .a и динамическая .so библиотеки. Сборка этих двух типов библиотек автоматически выполняются с разными флагами компиляции (для динамических библиотек генерируется т.н. position independent code с помощью -fPIC). Таким образом, одни и те же библиотечные исходники компилируются дважды (если не отключить статическую сборку). По умолчанию используются динамические библиотеки, для которых PIC code дает заметное преимущество. Для статических библиотек и executables PIC code дает небольшой проигрыш. Теперь обратим внимание на пакет mpfc (music player for console). $ cat mpfc-1.1.1/plugins/effect/echo/Makefile.am lib_LTLIBRARIES = libecho.la libdir = $(prefix)/lib/mpfc/effect libecho_la_SOURCES = echo.c INCLUDES = -I$(top_builddir)/src libecho_la_LIBADD = $(top_builddir)/src/util/libutil.a \ $(top_builddir)/src/cfg/libcfg.a $ Здесь мы видим, что "полноценная" libtool библиотека libecho.la как в статическом, так и в динамическом виде линкуется со вспомогательными статическими библиотеками libutil.a и libcfg.a. $ cat mpfc-1.1.1/src/util/Makefile.am noinst_LIBRARIES = libutil.a libutil_a_SOURCES = util.c ../util.h localedir = $(datadir)/locale DEFS = -DLOCALEDIR=\"$(localedir)\" @DEFS@ INCLUDES = -I$(top_builddir)/src $ Здесь мы видим, что библиотека libutil.a действительно является вспомогательной и не предназначена для установки (noinst_LIBRARIES), а предназначена только для статической компоновки в libecho.la и в некоторые другие библиотеки этого пакета. Таким образом, by design, в этом пакете статический non-piс код (libutil.a) будет "подмешиваться" в динамические библиотеки (libecho.so). Соответственно, такие динамические библиотеки не будут проходить проверку brp-verify_elf. К чести libtool надо сказать, что в таких ситуациях он выдает честное предупреждение: *** Warning: Linking the shared library libecho.la against the *** static library ../../../src/util/libutil.a is not portable! К "стыду" разработчиков надо сказать, что пакет mpfc не один подвержен этой напасти (сегодня я ещё исправил flac и буду дальше заниматься этим вопросом). Теперь предлагаю обсудить варианты решения проблемы: 1) Можно изменить структуру пакета (возможно, увеличив число полноценных библиотек и исключив вспомогательные статические библиотеки). 2) Обнаружив вспомогательные статические библиотеки, можно "насильно" заставить их собираться с -fPIC примерно следующим образом: %configure %__subst -p 's/%optflags/& %optflags_shared/g' .../Makefile %make_build Я пока предпочел второй вариант. --ryJZkp9/svQ58syV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAIBQafBKgtDjnu0YRAi7YAKDazS9Vt+uIGauUNBtRUvK2zm2JgwCgxQZW VKAXxsMlScTWG90XT+dJ3/w= =8Jaw -----END PGP SIGNATURE----- --ryJZkp9/svQ58syV--