素人翻訳

過剰結合(Overlinking)

目次

• 1 過剰結合
• 2 過剰結合とは何か
• 3 検出方法
  • 3.1 バイナリを調べる
  • 3.2 パッケージ構築に際して
• 4 修正方法
  • 4.1 pkg-config の問題
  • 4.2 libtool の問題
  • 4.3 色々な問題
  • 4.4 --as-needed
• 5 --as-needed で生じる問題
  • 5.1 下潜結合のライブラリ(underlinked)
  • 5.2 誤った結合順序
  • 5.3 同じシンボルが異なるライブラリに
• 6 参考

過剰結合とは何か

例：libpng 機能を要する emacs の構築にあたって、静的 PNG ライブラリを結合する場合、「-lz」を使う。ところが、動的結合だとこれでは拙い。zlib の版の上位番号が更新された時、emacs が zlib を全く使っていなくても libpng がそれを使用しているというだけで、emacs を再構築しなければならない。

検出方法

バイナリを調べる

「ldd -u -r」を使う。以下が例。

% ldd -u -r /usr/bin/emacs
Unused direct dependencies:

   /usr/lib/libXext.so.6
   /lib/libz.so.1

パッケージ構築に際して

ここで説明されている警告を見ることになる。(調査は spec-helper の strip_and_check_elf_files によって行われる。)

修正方法

pkg-config の問題

必要な結合印(linker flags)を得るために $(pkg-config --libs somefoo) を使用しているソフトウェアがある。pkg-config は「*.pc」文書の「Libs:」欄と「Requires:」欄を通じて結合印(linker flags)を得る。

しかしながら、多くの「*.pc」文書ではそれ自身の依存関係が誤って「Libs:」や「Requires:」に記述されている。当のパッケージだけが利用し、そのパッケージを用いる他のパッケージには知らせない類いの依存性は、「Libs.private:」と「Requires.private:」に記述されるべきであるにもかかわらず。(これには歴史的な理由がある。Requires.private と Libs.private は 0.18 版以前の pkg-config には存在せず、両者とも後方互換でないのだ。)

gtk+-2.0.pc からの例：

Requires: gdk-${target}-2.0 atk cairo

これは次のように記述するべき：

Requires.private: gdk-${target}-2.0 atk cairo

ffmpeg の libavcodec.pc からの例：

Libs: -L${libdir} -lavcodec -lz -pthread -lm -la52 -lfaac -lfaad -lmp3lame -lm -lnut -ltheora -logg -lvorbisenc -lvorbis -logg -lx264 -lm -lxvidcore -ldl -ldl -lX11 -lXext

これも次のように記述されるべき：

Libs.private: -lz -pthread -lm -la52 -lfaac -lfaad -lmp3lame -lm -lnut -ltheora -logg -lvorbisenc -lvorbis -logg -lx264 -lm -lxvidcore -ldl -ldl -lX11 -lXext
Libs: -L${libdir} -lavcodec

libtool の問題

libtool アーカイヴ(*.la)の中には使用されているライブラリの一覧表があり、ライブラリは再起的に記録されている。標準の libtool はこれらのライブラリを、動的に結合されるものも含めて、明示的に記述する。この点は debian からのパッチ(patch)で修正されている。

しかしながら、ソフトウェアには大抵それ自身の libtool が同梱されている。configure の前に「autoreconf」を走らせ、これを更新する方法もある。しかしこのやり方は失敗することもよくあるので、Mandriva は %configure と %configure2_5x で呼び出される「fix-libtool-overlinking」という指示文(script)を用意している。

libtool archives も見よ。

色々な問題

残念なことに、libtool と *.pc 文書を修正するだけでは十分ではない。

• xdm は -lXinerama を附けて構築されているが、本当は要らない。/usr/lib/X11/xdm/authdir だけが -lXinerama を必要としている。しかし Makefile を簡単にするために、同じ LDFLAGS が使われている。
• emacs は静的構築・動的構築の両方で -lz を附けて構築されているが、これは誤り。emacs の configure.in は修正されるべき。

コードを直し、上流の開発者に報告するのが、上記の問題の最良の修正方法だ。

--as-needed

正確に修正して上流の開発者に報告するのは骨が折れるし時間もかかる。--as-needed を使うのが簡単な直し方だ。Mandriva では2008年5月から広域の(global) --as-needed が使われている。

--as-needed で生じる問題

下潜結合のライブラリ(underlinked)

--as-needed によって問題が生じた場合、下潜結合(underlinked)のライブラリが原因かもしれない。

[me@mandrivapc]$ %define _disable_ld_as_needed 1 を使って問題を回避してはいけない。これはその場しのぎにしかならない。ライブラリ自体を修正するべき。(参考：fedora は prelink を導入した2003年には、もうこれらの問題を修正するパッチ(patches)を出していた。)

誤った結合順序

gcc -Wl,--as-needed -lfoo bar.o

これは良くない。「ld」は後ろに続く文書群の中から未解決のシンボルを探すから。そのため [me@mandrivapc]$ -lfoo は --as-needed を使用した場合、単に無視される。

ライブラリが *.o 文書の後に置かれるようにする。

gcc -Wl,--as-needed bar.o -lfoo

順序の誤りは通常、ライブラリを LDFLAGS に食わせた時に起きる。(このやり方は正しくない)

詳しい説明は Gentoo の --as-needed に関する素晴らしいページを見てほしい。

同じシンボルが異なるライブラリに

pcre と --as-needed の使用によって起こる領域違反(segfault) を見てほしい。

参考

• 過剰結合問題の優れた概説(debian のメーリング・リストにて)
• libtool と依存ライブラリについて
• --as-needed に関する Gentoo のページ
• --as-needed を標準で使用することによって起こりうる問題について(debian のメーリング・リストにて)

Dynamic Kernel Module  Support(DKMS)は、カーネルのソースコードに通常含まれていないソースから、カーネル部品を生成できるようにするプログラム／枠組み。新しいカーネルがインストールされた時、自動的にDKMS部品群が再構築される点が肝。

DKMSの特徴は、カーネルの新版がインストールされた際、全てのDKMS部品群を自動的に再コンパイルすること。これによってカーネル主要部分に含まれないドライバやデバイスもアップグレードを跨いで引き続き利用可能となる。

DKMSにはもう一つ利点がある。新しいドライバを稼働中のシステムにインストールするにあたって、システムのカーネルの版が何であっても、手動コンパイルや開発元が提供するコンパイル済みパッケージを必要としないことである。

DKMSは2003年にDELLのLinux開発チームが作ったものであり、Ubuntu、Debian、Fedora、SuSEをはじめとした多くの配布版に採用されている。DKMSはGNU General Public License (GPL)第2版以降に基づいて配布されるフリーソフトウェアである。

DKMSはRPMとDEBパッケージ形式の両方に対応しており、そのまま使える。