×

[PR]この広告は3ヶ月以上更新がないため表示されています。
ホームページを更新後24時間以内に表示されなくなります。

ライブラリ

特定の用途のために有用な機能をひとまとめにしたもので、外部のプログラムからこの中の機能を呼び出して使うことができる。

プログラムからライブラリの機能を使うには、ライブラリのヘッダファイルを取り込んでそのライブラリの使い方(API)に基づいたコードを記述してコンパイル時にライブラリとリンク(結合)する。

ライブラリ内の機能を使うためのリンクには、ライブラリ内の機能を外部プログラムに内蔵する方法(静的リンク/スタティックリンク)と、ライブラリとプログラムを分けてその実行時に機能を呼び出す方法(動的リンク/ダイナミックリンク)とがある。

静的リンクと動的リンク

表35 静的リンクと動的リンク

項目静的(スタティック)リンク動的(ダイナミック)リンク
ライブラリ機能の使用方法内蔵されたものを使用実行時に共有オブジェクトとリンクして機能を呼び出す
プログラム単独での動作可否不可(共有オブジェクトがないと起動に失敗する)
ライブラリのファイル形式ar書庫(*.a)共有オブジェクト(*.so.*, *.so)
ファイルサイズ内蔵する分大きい内蔵しないので小さい
使用されるライブラリのバージョンリンク時のバージョン共有オブジェクトのバージョン

静的リンクと動的リンクはそれぞれメリットとデメリットがあるが、一般的に使われるのは動的リンクとなっている。

[ヒント]ヒント

静的リンクの実用的な使い方の例として、Cライブラリ関係が壊れるなどして通常のプログラムが動作しなくなったときなどのために端末シェルやbusybox(復旧時など向けの基本コマンド集)の静的リンク版がディストリのパッケージ(-static付きのパッケージ名)として用意されている場合がある。

ライブラリの開発パッケージ

一般的にGNU/Linux上のライブラリには共有オブジェクトを用いた動的リンクが用いられるが、ライブラリを使用する実行形式は主に共有オブジェクト(lib[名前].so.[「X.Y.Z」形式のバージョン])とそれを指し示す動的リンク用のシンボリックリンク(lib[名前].so.[バージョン])のみを必要とし、ライブラリを用いたプログラムをコンパイルする際に用いるヘッダファイルやビルド時のリンク処理に用いる拡張子.soのシンボリックリンク(lib[名前].so)などのファイルは(ライブラリに動的リンクする実行形式からは)必要とはならない。そのため、これらのファイルは共有オブジェクトとは別の開発パッケージとして分離されていることが多い。

pkgconfigで用いる.pcファイルも開発パッケージの一部。

開発パッケージのパッケージ名は、パッケージにRPM形式を使用しているディストリではlib[名前とバージョン]-devel,DEB形式を使用しているディストリではlib[名前とバージョン]-devのパッケージ名となっているのが一般的。

GCCにおけるライブラリのリンク操作

  • リンクしたいライブラリの.soファイル(動的リンク時)もしくは.aファイル(静的リンク時)のファイル名のlib[名前].[soもしくはa]の名前部分を-l[名前]として指定(複数可)

  • 上のように指定すると、ライブラリの探索パスからその名前に合ったファイル名のライブラリファイルを探索し、あればそれをリンクし、なければリンカldcannot find -l[名前]というエラーメッセージを出力して処理は失敗する

  • 標準のライブラリ探索パスは多くの場合/usr/lib/で、これ以外の場所から探索したい場合は-L[探索ディレクトリの場所]オプションを付ける(複数可)

  • ライブラリを静的リンクしたい場合は-staticオプションを付ける

[注記]メモ

pkgconfigをサポートする(.pcファイルを含む)ライブラリを用いたプログラムをビルドする際のリンクにはpkg-config --libsの出力をそのままオプションとして渡すことができる。

例46 libfoo(libfoo.so),libbar(libbar.so)を追加の探索パス/path/to/dir付きで探索してリンクする

$ gcc [ソースやオブジェクトのファイル...] -o [出力ファイル] -lfoo -lbar -L/path/to/libdir

例47 GLib 2を用いた単一のソースファイルのコンパイル

$ gcc $(pkg-config --cflags --libs glib-2.0) [ソースファイル] -o [出力ファイル]

関連セクション

multilib環境

x86_64版のディストリではx86_32版とx86_64版の両方のプログラムが動作し、ライブラリについても同様となるが、あるライブラリについて(同一のCPUがサポートする)複数のアーキテクチャ向けにビルドされたものがシステム上に混在する/できる環境をmultilib環境と呼ぶ。

multilib環境では、ライブラリの配置ディレクトリが動作対象のアーキテクチャごとに異なるが、そのディレクトリの位置・名前についてはディストリ(系統による違いが大きい)やそのバージョンによって異なる。

関連セクション

GObject

  • オブジェクト指向プログラミングをC言語で行うために用いられるライブラリ

  • GTK+やGStreamerなどのGNOME系のライブラリで主に用いられる

  • オブジェクト指向言語のVala言語を用いると扱いやすい

GObject introspection

  • GObjectに基づいたライブラリ内のクラスなどを高レベルのオブジェクト指向言語から容易に利用できるようにするための仕組み

    • CPU負荷のかかる処理や低レベルな処理に向いているC言語の世界

    • 複雑なプログラムを記述しやすい高レベルのオブジェクト指向言語の世界

    の間の有用な架け橋として機能することを1つの目的とする

  • 言語バインディングと親和性が高く、ライブラリから言語バインディングを自動生成(g-ir-scanner)してメンテナンスしやすくできる(手動メンテナンスによる問題を解消することもできる)上に、GObject introspectionに対する言語バインディング(例:Python向けのPyGI)があればGObject introspection対応ライブラリは基本的に全て利用可能となる

  • 自動生成されたバインディングのデータは.girという拡張子のXML文書となり、/usr/share/gir-[バージョン]/へ保存される

  • GObject introspectionに対する言語バインディングからは、.girファイルをバイナリ形式に変換(g-ir-compiler)した.typelibファイルが用いられる(逆の変換はg-ir-generate)

  • Debian/Ubuntu系のディストリでは.typelibファイルはgir[バージョン]-[ライブラリ名]形式の名前のパッケージを追加インストールする必要があり、PyGIなどを使用しているパッケージからはライブラリごとのこれらのパッケージ群も必要となる

  • .typelibファイルは/usr/lib/girepository-[バージョン]/へ配置され、GObject introspectionに対する言語バインディングからパッケージに応じたファイルが参照された後、.typelibファイルに対応するライブラリが読み込まれてライブラリ内の機能が呼び出せる状態になる