忍者ブログ

素人翻訳

適当に翻訳する。

下潜結合(underlinking)

出典:Underlinking
許諾:Creative Common - Attibution - ShareAlike 3.0.

下潜結合(Underlinking)
目次
下潜結合とは何か
単純な例

バイナリが使用しているシンボルに、直接結合されたライブラリによっては提供されないものが含まれている時、その状態を下潜結合という。例えば、libeb では zlib の「deflate」が使われている。しかし libeb の構築にあたっては -lz は付けられていない。このやり方は共有ライブラリでは認められている。

objdump -p /usr/lib/libeb.so | grep NEEDED
   NEEDED   libnsl.so.1
   NEEDED   libresolv.so.2
   NEEDED   libc.so.6

libeb を利用するプログラムには、明示的に libz を結合する必要がある。直接 libz を使っていなくても。

% echo 'main() { eb_log("foo"); }' > t.c
% gcc t.c -leb -lz
% gcc t.c -leb
/usr/lib/libeb.so: undefined reference to `inflateEnd'
/usr/lib/libeb.so: undefined reference to `deflate'
...
collect2: ld returned 1 exit status

上のプログラムは -Wl,--as-needed を用いて結合してはいけない。(過剰結合)

% gcc t.c -Wl,--as-needed -leb -lz
/usr/lib/libeb.so: undefined reference to `inflateEnd'
/usr/lib/libeb.so: undefined reference to `deflate'
...
collect2: ld returned 1 exit status
表に現れない例

例えば、librsvg は libm の「tan」を使用しているが、構築時に「-lm」は付けられていない。

この librsvg と libm を基にした下潜結合は、先の単純な例とは異なり、librsvg を伴って構築されたプログラムに何の影響も及ぼさない。これは librsvg が多くの共有ライブラリと結合されており、その共有ライブラリの中に libm と結合されているものが存在することに因る。

なぜ下潜結合は有害なのか
プログラムに有害

新しい版の libfoo が公開され、今度の libfoo は zlib を使用している、しかし libfoo 構築時に zlib は結合していない、この場合どうなるか。libfoo を使用している全てのプログラムは「-lz」を付けて構築し直すことになる。

--as-needed が使えない

上で述べたように、下潜結合しているライブラリを付してプログラムを構築する時、--as-needed を使ってはいけない。

例:

% gcc -Wl,--as-needed conftest.c -lgtk -lgdk -lgmodule -lgthread -lglib -lpthread -ldl -lXi -lXext -lX11 -lm
/usr/lib/libgtk.so: undefined reference to `gdk_window_foreign_new'
/usr/lib/libgtk.so: undefined reference to `gdk_drag_find_window'
/usr/lib/libgtk.so: undefined reference to `gdk_colormap_get_visual'
...

「-lgdk」が挙げられているが、conftest.c はこれを使用していないので、--as-needed 指定によって捨てられる。

解決方法は /usr/lib/libgtk.so を適切に libgdk と結合すること。未定義の参照が libgtk.so に含まれないようにする。

配布に不便

配布に際しては、パッケージの間の依存関係を知る必要がある。下潜結合状態のライブラリがあると、再構築するべきか判断できなくなる。(BuildRequires を確認すれば話は別だが。) また、これによって過剰結合せざるを得なくなる。

例:

libeb を必要とするプログラム foo は libeb と libz を付けて構築される。もし ABI の異なる新しい libz が公開されたら:

  • foo を無駄に再構築しなければならない。(過剰結合)
  • libeb も再構築する必要がある。しかしこの情報は隠されている。ライブラリの依存関係を自動で処理する機能は役に立たない。
検出方法
パッケージ構築に際して
ld の --no-undefined 指定

ROSA Linux では「-Wl,--no-undefined」が標準で LDFLAGS に設定されている。これによって全ての共有ライブラリ(DSO)が下潜結合されないようになる。足りないライブラリがあると構築に失敗する。例:

% echo 'main() { deflate(); }' > libfoo.c
% gcc -shared libfoo.c
% gcc -shared libfoo.c -Wl,--no-undefined
ccEqBIQo.o: In function `main':
libfoo.c:(.text+0x12): undefined reference to `deflate'
collect2: ld returned 1 exit status

--no-undefined を標準で用いると問題が起きることもある。特に plugins/modules に。下記を見よ

spec-helper の警告

ここで説明されている警告を見ることがあるだろう。(spec-helper の strip_and_check_elf_files によって調べられる。)

しかしこの検査は ldd -r を使っており、検出できない場合もある。

共有ライブラリを調べる

「ldd -r」を使う。例:

% ldd -r /usr/lib/libeb.so.10.0.2 >/dev/null
undefined symbol: inflateEnd   (/usr/lib/libeb.so.10.0.2)
undefined symbol: deflate   (/usr/lib/libeb.so.10.0.2)
undefined symbol: deflateInit_   (/usr/lib/libeb.so.10.0.2)
undefined symbol: inflate   (/usr/lib/libeb.so.10.0.2)
undefined symbol: deflateEnd   (/usr/lib/libeb.so.10.0.2)
undefined symbol: inflateInit_   (/usr/lib/libeb.so.10.0.2)

「ldd -r」では十分でない。「表に現れない場合」を検出できない。構築時に --no-unneeded を使えばあらゆる場合に対応できる。

修正方法
libtool を使ったプログラム

修正の例:

distcache
--- distcache-1.5.1/ssl/libnalssl/Makefile.am 2004-04-30 13:09:14.000000000 -0400
+++ distcache-1.5.1.oden/ssl/libnalssl/Makefile.am 2008-05-21 12:11:36.000000000 -0400
@@ -3,3 +3,4 @@
lib_LTLIBRARIES = libnalssl.la
libnalssl_la_SOURCES = bss_nal.c
libnalssl_la_LDFLAGS = -version-info 1:1:0
+libnalssl_la_LIBADD = ../../libnal/libnal.la
gtk+1.2
--- gtk+-1.2.10/gtk/Makefile.am.gtkgdkdep 2003-10-15 15:20:27.000000000 -0400
+++ gtk+-1.2.10/gtk/Makefile.am 2003-10-15 15:22:50.000000000 -0400
@@ -23,6 +23,10 @@

# libtool stuff: set version and export symbols for resolving
libgtkincludedir = $(includedir)/gtk-1.2/gtk
+
+libgtk_la_DEPENDENCIES = $(top_builddir)/gdk/libgdk.la
+libgtk_la_LIBADD = $(top_builddir)/gdk/libgdk.la
+
libgtk_la_LDFLAGS = @STRIP_BEGIN@ \
-version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) \
-release $(LT_RELEASE) \
id3lib

make libid3_la_LIBADD="-lstdc++ -lz" で修正できる。

二つの問題に気をつける。

  • -lz は付けられていない。
  • libtool --mode=link g++ は正しくない。なぜなら libtool は共有ライブラリとの結合に g++ ではなく gcc を用いるから。正しい命令は:
    libtool --tag=CXX --mode=link g++。残念なことに --tag=CXX は libtool 1.4b(2001年7月)から導入された機能であり、id3lib の libtool では扱えない。
--no-undefined で生じる問題

mpg123 を例に採る。プラグインは呼出し元のプログラムで定義された関数を使用している。

% ldd -r /usr/lib/mpg123/output_sdl.so >/dev/null
undefined symbol: sfifo_close (/usr/lib/mpg123/output_sdl.so)
undefined symbol: sfifo_init (/usr/lib/mpg123/output_sdl.so)
undefined symbol: sfifo_flush (/usr/lib/mpg123/output_sdl.so)
undefined symbol: sfifo_read (/usr/lib/mpg123/output_sdl.so)
undefined symbol: sfifo_write (/usr/lib/mpg123/output_sdl.so)
% objdump -T /usr/bin/mpg123 | grep sfifo
0805ac30 g DF .text 00000013 Base sfifo_flush
0805ac80 g DF .text 0000007a Base sfifo_init
0805adc0 g DF .text 000000b8 Base sfifo_read
0805ad00 g DF .text 000000c0 Base sfifo_write
0805ac50 g DF .text 00000021 Base sfifo_close

ここに挙げられたシンボル(プラグインの中では解決されない)は、そのプラグインを呼び出したプログラムの一部である。(以下のプログラムのプラグインが例。gnome-settings-daemon、compiz*、emerald、libxslt、lxpanel など。)

これらの特別なプログラムで下潜結合を禁じるには、次の一文を仕様文書に加える。

%define _disable_ld_no_undefined 1

この文が必要ないことも多々ある。というのは、%configure で呼び出される drop-ld-no-undefined-for-shared-lib-modules-in-libtool によって ltmain.sh/libtool が修正され、共有ライブラリ構築時に --no-undefined が無視されるようになるから。

より良い修正方法は libtool が -module 指定付きで正しく呼ばれるようにすること。(時々 -export-dynamic しか使われないことがある。両方用いられるべきなのに。)

Perl 機能群

ROSA Linux は Perl 機能群に対して --no-undefined 指定をしていない。Perl 機能群は構築の際、LDFLAGS を利用しないから。

Perl 機能群は libperl と結合されないので、むしろ指定するべきでない。

Ruby 機能群

Ruby 機能群は libruby に対して結合されるので --no-undefined は必要ない。ruby/GNOME2 が壊れてしまうので、機能群構築にあたって --no-undefined は元々使われていない。このパッケージは複数の機能群(glib、gtk、atk、poppler など)を構築するが、これらは結合されない。そのかわりに、ruby コードによって然るべき順序で読込まれる。この特別なパッケージを修正するのが筋だが、今のところ ruby パッケージの方に解決処理が入っている。

PR

コメント

お名前
タイトル
文字色
メールアドレス
URL
コメント
パスワード Vodafone絵文字 i-mode絵文字 Ezweb絵文字

カレンダー

03 2024/04 05
S M T W T F S
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30

最新コメント

[08/18 NONAME]
[05/18 NONAME]
[04/09 NONAME]
[03/21 NONAME]
[03/20 NONAME]

最新記事

ブログ内検索

広告

バーコード

広告