2013年8月22日木曜日

LibreOfficeのソースからのビルド:準備編

ビルド環境はCentOS6で行う。手順1.と2.については前回も書きましたが、あらためて記載する。(そのわりには、fontconfigの件抜いちゃってますが)

1.
まずビルド環境を整備するのに、以下のコマンドを使えとlibreofficeのwikiに書いてあった。

$ sudo yum-builddep libreoffice # RedHat

しかし、何かlibreoffice-3.0.4のソースRPMが見つからないといってエラーで返される。
どうもビルドに必要なライブラリを落としてくる(RedHat系なので、当然rpmパッケージでDLします)が、ソースまでrpmパッケージで探そうとしているらしい。(自分で最新ソースをDLしてくるからいいのに・・・・)

結局、これで必要なものがDLされたかは疑問。(実際、この後あれが足りない、これが足りないと自分でライブラリをインストールしまくる必要があったのでダメだったんでしょう)

2.
続いてconfigureに相当する、autogen.sh(gitしてきたところに入っている)を実行する。とりあえずオプションなしで。(全機能ビルドしようとしちゃうだろうけど、最初は全然わからないので。)

まずでてきたのが、javac(javaコンパイラ)がないとのこと。
OSのインストール状況を見てみるとOpenJDKのruntimeが入っていた。(だからjavaはあるが、javacはない)
OpenJDK-Developnment Environmentをソフトウェア管理ツールを使用してインストール、これでjavacは解決した。

3.
次にでてきたのが、gperfがないということ。(ハッシュ関数生成用ライブラリだそうです)以下のコマンドで直接インストール。

$ sudo yum install gperf

4.
次にでてきたのが、インストール済みのdoxygen(設計書自動生成ツール)のバージョンが古い(現在、1.6が入っている。 1.8.4以上が欲しいといってきた)ということ。yum updateをやってみたが、CentOSのリポジトリではまだ新しいバージョンが登録されてないらしく、現状で最新とのこと。
特にdoxygenの出力が欲しいわけではないので、これをスルーするオプションを追加。(親切にもautogen.shが提案してきてくれた)

./autogen.sh --without-doxygen

5.
次にでてきたのが、libjpegのヘッダファイルがないということ。libjpegのパッケージ自体は入っているが、ヘッダファイルということは開発用のパッケージが必要ということと判断し、以下のコマンドでインストール。

$ sudo yum install libjpeg-devel

6.
次にでてきたのが、libxsltがないということ。先ほどのlibjpegと同じことだろうと考え、以下のコマンドで開発用パッケージをインストール。

$ sudo yum install libxslt-devel

7.
次にでてきたのが、X関係の開発環境がないということ。さすがにこれはマニュアルでインストールしていると大変なので、ソフトウェア管理ツールを使い、それらしいものをかたっぱしからインストール。(ほとんどインストールされていない状態でした。OSインストール時に昔は「X開発環境」という選択肢があったんですが、今回のは単なる「開発環境」の選択肢しかなくって、結果g++が入ってくれた程度でした。)

8.
次にでてきたのが、gconfがないということ。でもパッケージ関係で探すとgconf-editorしか見つかりません。これはgnomeの設定用ツールでGUI込みのものです。でも要求されているのは、GUIは要らないから設定ファイル関係を操作するものらしいんですが、単独ではパッケージが見つかりません。
LibreOfficeがなんでこんなもの必要なんだろうと調べてみると、gnome設定を直接サポートするパッケージ(libreofice-gnome)をビルドするのに必要ならしい。そもそもこの機能自体まだexperimental(実験的)なものなので、はずします。

./autogen.sh --without-doxygen --disable-gconf

9.
次にでてきたのが、dbus-glib-1がないということ。glibというからにはグラフィック・ライブラリに関するものと思われるが、聞いたことのない名称。ぐぐってみると、"GLb Bindings for D-Bus"というものらしく、D-Busというのが一種の(軽量な)プロセス間通信を提供するもので、元々はKDEプロジェクトで開発されたものが今では様々なものに移植され使われているとのこと。以下のコマンドで直接インストール。

$ sudo yum install dbus-glib-devel

10.
次にでてきたのが、GTK-pluginがないとのこと。先ほどgconfをあきらめたので、これもdisableにすることにする。

./autogen.sh --without-doxygen --disable-gconf --disable-gtk

(おそらくこのあたりまでLibreOfficeに入れようとすると、gnomeやGTKのソースが必要になってくるんだろう。そうなると、そもそもgnome自体も標準でディストリビューションに入っている物から、自分でビルドしたものに変えないといけなくなるだろうし・・・手間が際限なく増えていく。)

11.
次にでてきたのが、GSTREAMERがないとのこと。(何者かと思ったら、streaming media frameworkとのこと。)調べて、以下の2つをインストール。

$ sudo yum install gstreamer-devl
$ sudo yum install gstreamer-plugins-base-devel

12.
次にでてきたのが、libGLUがないとのこと。(OpenGLのライブラリのうちのGLU)以下のコマンドでインストール。

$ sudo yum install mesa-libGLU-devel

13.
次にでてきたのが、antがないとのこと。(java版のmake。なんでこんなものまで使うんだ?)以下のコマンドでインストール。

$ sudo yum install ant

14.
次にでてきたのが、JUnitがないとのこと。(javaの単体試験モジュール。LibreOffice内にjava開発機能が含まれているのか?)さすがにこれはパス。

./autogen.sh --without-doxygen --disable-gconf --disable-gtk --without-junit

とりあえずこれでMakefileはできました。




2013年8月18日日曜日

builddepについて

ふとLibreOfficeをソースからフル・ビルドしてやろうと思い立ち、調べてみると案の定かなりの難物の模様。
まずソースをgitでおとしてこないといけませんが、これがかなり時間がかかり(家はフレッツ光の一般家庭用です、マンションなんかのシェアタイプとは違います)、1GB以上をDLするのに数時間かかりました。(速度が出ないところをみると、gitのサーバの能力の問題と思われます)
普通ならまず、./configureなんですが、最初に./autogen.shを実行しろとのこと。./configureの代わりみたいなんですが、FONTCONFIGのところでどうしてもエラーがでます。ビルドマシンはCentOS6.4ですが、調べてみるとパッケージはちゃんと入っています。(2.2以上を要求してきましたが、2.8が入っています)

ちょこちょこ調べてみると、同じエラーで悩んでいる方も多く、ビルド環境を整えるために以下を行えとありました。

# yum-builddep libreoffice  # RedHat系

# apt-get build-dep libreoffice # Debian, Ubuntu系

ところがこれを実行しようとすると、どうもソースパッケージ(CentOSならソールRPM)を探しに行ってしまい、たまたま最新(4.x系)が見つからなくてエラーになります。
いやちょっと何よこれ、とコマンドの意味を調べたら、当該パッケージをビルドするのに必要なパッケージをとってくるものとのこと。ライブラリ関係はいいんですが、肝心のソースは本家のものでやらせてよ・・・・

ということで、あきらめて設定を手作業で修正してやらないとだめなようです。

PS:
英語のメーリングリストで有用な情報を見つけました。この./autogen.shではビルドに必要なヘッダファイル(*.h)があるかを見ているようで、パッケージとしてfontconfigが入っていてもだめで、fontconfig-develが入ってないとだめとのこと。早速インストールです。

# yum install fontconfig-devel

./autogen.shが無事先に進むようになりましたが、、、今後はPerlのところでひっかかりました。LibreOfficeを開発している人、どんなシステム環境で作業してるんだ\(-o-)/

2013年8月16日金曜日

Linuxプログラムのメモリ不足

人の作ったプログラム何ですが、やたらとmalloc(正確にはcallocの方)を使ったCプログラムがありました。それの動きがどうもおかしい(不安定)なんで、見てみると数百MBのデータファイルを最初に読み込ませていました。(データファイルの大きさは、利用する状況によって変わります)動いているマシンが、RHEL6 32bitとのことなんで、明らかにmallocに失敗していると思われます。
ところが、このプログラムmallocの結果を全然チェックしておらず、catchもしていません。またプログラムを使っている人たちもLinuxに関しては素人ということで、何が悪いのか理解させるのに一苦労。試しにちょっとサンプルプログラムを作って見ました。


#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define MALLOC_SIZE 100000

int main()
{
  int i,j;
  int *pt;

  for (i=0; i<10000; i++) {
    pt = (int *)calloc( MALLOC_SIZE, sizeof(int));
    if (pt == NULL) {
      printf("## calloc error!! i= %d ##\n", i);
      exit(0);
    }

    for (j=0; j<MALLOC_SIZE; j++) {
      pt[j] = i;
    }

  }

}

取得したメモリに値を書き込んでいるのは、こうして実際に何か使わないと、それまでは本当にメモリの取得につながらないからです。(最初、これで苦労しました)

さてこれで実行してみるとerrorが出たときの、iの値は8,017、あれ?毎回400KB近くのメモリを取得しているはずなのに、これだと3.2GBのメモリを取得したことになっちゃうぞ?確か、Linuxだと1プロセスの最大サイズは2GB弱で、そのうちStackが1GB、Heapが700MBくらいだったはず。おおすぎます。
そこでValgrindでチェックしてみると、i=6,910 2.764GBのheap要求がされたとのこと。(計算が合う)再度、ぐぐりましたが、どうも1プロセスでのサイズ制限はなくなり、4GBのどの空間をKernel用、Stack用、Heap用に用途わけするようになったみたいです。
マシンを占有できれば大きなプログラムを動かせますが、動作解析が更にやっかいになったようです。