ライブラリと分割コンパイル

2023年7月
日	月	火	水	木	金	土
	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	31

巨大なプログラムを作ってくると、プログラムのコンパイルに時間がかかる。こういった場合には、共有できる処理であればライブラリにまとめたり、分割コンパイルといった方法をとる。

ライブラリ

C言語でプログラムを作っている時、printf() や scanf() といった関数を使うが、こういった組み込み関数のプログラムはどこに書かれているのだろうか？

ソースプログラムがコンパイルする際には、コンパイラ(compiler)によるコンパイル処理(compiler)、リンカ(linker or linkage editor)によるリンク処理(link)が行われる。この時に、printf()やscanf() の機械語(組み込み関数などのライブラリの内容)が実行プログラム a.out の中に埋め込まれる。通常は、コンパイルとリンク処理は一連の処理として実行される。

helloworld.c ソースプログラム
  ↓ compiler $ gcc -c helloworld.c  (コンパイルだけ行う)
helloworld.o オブジェクトファイル(中間コード)
  ↓ linker   $ gcc helloworld.o     (リンク処理を行う)
 (+) ← libgcc.a ライブラリ(printf, scanf....)
  ↓          $ ./a.out
a.out 実行プログラム

静的リンクライブラリと動的リンクライブラリ

しかし、printf() や scanf() のような組み込み関数の機械語が実行プログラムの中に単純に埋め込まれると、

よく使われるprintf()やscanf()の処理は、沢山の実行プログラムの中に埋め込まれる。
そして、組み込み関数を使ったプログラムが複数実行されると、実行中のメモリに複数の組み込み関数の処理が配置されてメモリの無駄が発生する。
その組み込み関数に間違いがあった場合、その組み込み関数を使った実行プログラムをすべて再コンパイルしないといけなくなる。

リンクされたプログラムの機械語が実行プログラムに埋め込まれる方式は、静的リンクライブラリと呼ぶ。

しかし、静的リンクライブラリの方式は、実行時の命令の領域のムダや、ライブラリに間違いがあった場合の再コンパイルの手間があるため、動的リンクライブラリ方式(共有ライブラリ方式)がとられる。

動的リンクライブラリでは、プログラム内には動的リンクを参照するための必要最小限の命令が埋め込まれ、命令の実体は OS が動的リンクライブラリとして管理する。

Linux では、静的リンクライブラリのファイルは、lib～.a といった名前で保存され、動的リンクライブラリは、lib～.so という名前で保存されている。 Windows であれば、拡張子が ～.DLL のファイルが動的リンクライブラリである。

OS にとって必須の動的リンクライブラリは /lib 配下に保存されるが、ユーザが独自にインストールするパッケージの場合 /lib のアクセス権限の都合で別の場所に保存されるかもしれない。この場合、その独自パッケージを起動する時に、動的リンクライブラリの保存場所を見つけ出す必要がある。Linux では 環境変数 LD_LIBRARY_PATH に自分が利用する動的リンクライブラリの保存場所を記載すれば、OS がプログラム起動時に動的リンクライブラリを見つけてくれる。

分割コンパイル

複数人でプログラムを開発する場合、1つのファイルを全員で編集するのは混乱してしまう。例えば、ちょうど情報構造論で説明している、リスト処理のようなプログラムであれば、List 構造の構造体、cons(),print() といったList 構造を操作する関数を作る人と、そのそれらの関数を利用するプログラムを書く人に分かれてプログラム開発をすれば混乱も減らせる。そして、それぞれ別のファイルになっている方が開発しやすい。

list.h : ヘッダファイル – 構造体の宣言や関数のプロトタイプ宣言や変数のextern宣言などを記載
list.c : リスト処理の cons,print などの処理内容を記載
main.c : cons,print を使った処理を記載

#include “ヘッダファイル”

自作のヘッダファイルを読み込む場合は、#include “list.h“ のように記載する。

#include で、ヘッダファイルを < > で囲むと、/usr/include フォルダから探してくれる。” “ で囲むと、ソースプログラムと同じフォルダの中からヘッダファイルを探す。

プロトタイプ宣言と extern 宣言

ヘッダファイルには、list.c と main.c の両方で使われるデータ構造、関数、変数の宣言を記載する。関数は、引数の型や返り値の型を記載した struct List* cons( int , struct List*) ; といったプロトタイプ宣言を記載する。変数については、変数の型だけを宣言する extern struct List* stack ; といった extern 宣言を記載する。

// list.h -----------------------------
// リスト構造の宣言
struct List {
  int data ;
  struct List* next ;
} ;

// リスト操作の関数のプロトタイプ宣言
extern struct List* cons( int , struct List* ) ;
extern void print( struct List* ) ;

// stack の extern 宣言
extern struct List* stack ;

// スタック操作関数のプロトタイプ宣言
extern void push( int ) ;
extern int  pop()

// list.c -----------------------------
#include <stdio.h>
#include <stdlib.h>

#include "list.hxx"

// リストの要素を作る
struct List* cons( int x , struct List* n ) {
  struct List* ans = (struct List*)malloc( sizeof( struct List ) ) ;
  if ( ans != NULL ) {
    ans->data = x ;
    ans->next = n ;
  }
  return ans ;
}
// 全要素の出力
void print( struct List* p ) {
  for( ; p != NULL ; p = p->next )
    printf( "%d " , p->data ) ;
  printf( "\n" ) ;
}
// stack の実体
struct List* stack = NULL ;
// スタックに x を保存
void push( int x ) {
  stack = cons( x , stack ) ;
}
// スタックの先頭を取り出す
int pop() {
  int ans = stack->data ;
  struct List* d = stack ;
  stack = stack->next ;
  free( d ) ;
  return ans ;
}

// main.c -----------------------------
#include <stdio.h>

#include "list.hxx"

int main() {
  struct List* top = cons( 1 , cons( 2 , cons( 3 , NULL ) ) ) ;
  print( top ) ;

  push( 11 ) ; push( 22 ) ; push( 33 ) ;
  printf( "%d\n" , pop() ) ;
  printf( "%d\n" , pop() ) ;
  printf( "%d\n" , pop() ) ;
  return 0 ;
}

分割コンパイルの作業を確認するために、以下のコマンドを実行してみよう。

((( 一度にコンパイルする方法 )))
guest00@nitfcei:~$ cp /home0/Challenge/seg-compile/* .
guest00@nitfcei:~$ gcc list.c main.c
guest00@nitfcei:~$ ./a.out
# 正しく実行できる。
 
((( 失敗するコンパイル )))
guest00@nitfcei:~$ gcc list.c
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start':
(.text+0x24): undefined reference to `main'
collect2: error: ld returned 1 exit status
# list.c の中に main() が無いからエラー
 
guest00@nitfcei:~$ gcc main.c
/usr/bin/ld: /tmp/ccxr4Fif.o: in function `main':
main.c:(.text+0x17): undefined reference to `cons'
/usr/bin/ld: main.c:(.text+0x24): undefined reference to `cons'
/usr/bin/ld: main.c:(.text+0x41): undefined reference to `print'
:
collect2: error: ld returned 1 exit status
# main.c の中に、cons(),print(),push(),pop() が無いからエラー
 
((( プログラムをひとつづつコンパイル )))
guest00@nitfcei:~$ gcc -c list.c           # list.o を作る
guest00@nitfcei:~$ gcc -c main.c           # main.o を作る
guest00@nitfcei:~$ gcc list.o main.o       # list.o と main.o から a.out を作る
guest00@nitfcei:~$ ./a.out
# 正しく実行できる。

make と Makefile

上記のように分割コンパイルのためにファイルを分割すると、実行プログラムを生成するには以下のコマンドを実行する必要がある。

gcc -c list.c (list.o を作る)
gcc -c main.c (main.o を作る)
gcc list.o main.o (list.oとmain.oを使って a.out を作る)

また、プログラムのデバッグ作業中ですでに list.o , main.o , a.out が生成されている状態で、main.c の中に間違いを見つけて修正した場合、list.o を作るための手順1 は不要となる。例えば list.c が巨大なプログラムであれば、手順1を省略できれば、コンパイル時間も短くできる。一方で、どのファイルを編集したから、どの手順は不要…といった判断をプログラマーが考えるのは面倒だったりする。

こういった一部の修正の場合に、必要最小限の手順で目的の実行プログラムを生成するためのツールが make であり、どのファイルを利用してどのファイルが作られるのかといった依存関係と、どういった手順を実行するのかといったことを記述するファイルが Makefile である。

### Makefile ###
# a.out を作るには list.o , main.o が必要
a.out:  list.o main.o      # 最終的に生成する a.out の依存関係を最初に書く
        gcc list.o main.o

# list.o は list.c , list.h に依存
list.o: list.c list.h
        gcc -c list.c

# main.o は main.c , list.h に依存
main.o: main.c list.h
        gcc -c main.c

clean:; rm *.o a.out       # 仮想ターゲット: make clean と打つと、rm *.o a.out を実行してくれる。

list.h , list.c , main.c , Makefile

Makefile では、依存関係と処理を以下の様に記載する。make コマンドは、ディレクトリ内の Makefile を読み込み、ターゲットファイルのタイムスタンプと依存ファイルのタイムスタンプを比較し、依存ファイルの方が新しい場合(もしくはターゲットファイルが無い場合)、ターゲットを生成するための処理が行われる。

ターゲットファイル: 依存ファイル ...
      ターゲットファイルを生成する処理    # 行の先頭の空白は"タブ"を使うこと

理解確認

理解確認のForms(ライブラリと分割コンパイル)

電子情報工学科

リンク集

検索・リンク