FreeBSD 11-STABLE symbol の 'KERNBASE' can not be undef の件2017年10月11日 12時30分08秒

取り合えず、どの変更が原因か調べる。

前回のカーネルバージョンは 324186。 324421 は既に駄目。 324300 も駄目。 324299 は大丈夫。

コンパイルエラーを手っ取り早く見付ける為なので、モジュールは全て無効にする。

% cd /usr/src
% make buildkernel -j 3 MODULES_OVERRIDE=''
もしかしたら、一ファイルだけをコンパイルする方法もあるのかも知れないが、これで十分。

問題を見付けたかと思ったら、rm /usr/obj/usr/src/sys/GENERIC/mpboot.o の後に、324300 を試したら大丈夫。324385 は大丈夫。324400 は大丈夫。324472 も大丈夫。結局 HEAD に戻しても大丈夫。ファイルを消したら何が変わったのだろうか…

FreeBSD 11-CURRENT で buildworld 用の ccache2015年10月20日 07時30分23秒

[CFT] Buildworld ccache support にて、world-ccache.diff が投稿された。

最近、buildworld をよく行うので、高速化に、distcc と ccache を見ていた。buildworld は三段階以上にわたって、CC を置き換えて行くので、一般的に ccache の設定では出来ないなと結論が出ていたところ。

ccache よりも distcc に興味を持っていたのだが、折角なのでメモ。

FreeBSD 11-CURRENT で .depend を削除して速くなった2015年10月07日 11時42分54秒

buildworld の二回目に全てが作り直される動作は修正された。

しかし、手元での CURRENT-11 の buildworld を眺めていると、legacy と toolchain のターゲットのところで、clang は必ず、それ以外にもいくつかのプログラムもほぼ必ず再構築されていた。svn update を行っていない時でも、clang がこの二つのステージで作り直されるのはおかしい。

/usr/src/Makefile と /usr/src/Makefile.inc。それに /usr/src/share/mk/ のファイルを目を通すが明示的にコンパイルを引き起こす様な記述はない。そうなると、依存関係が怪しいと言うことになる。そこで、/usr/obj/usr/srcc/tmp 以下の .depend の日付を見ると八月中旬の物になっている。

% find /usr/obj/usr/src/tmp -name .depend -ls
% find /usr/obj/usr/src/tmp -name .depend | xargs rm
そこで、一旦削除して buildworld を行った。今回は clang が再構築されない。Makefile を見ていても tmp 以下の ブートストラップの .depend は作り直されないようで、時おり掃除してやる必要がありそうだ。

buildworld の clang 再コンパイル修正が入った2015年09月24日 13時25分16秒

最近は FreeBSD CURRENT をよく追いかけている。どうも buildworld を再度実行した時に clang が不必要に作り直されているのには最近気が付いていた。

最初に見た二、三週間前は、NFS や NULLFS を使っていたせいかと思っていた。しかし、何度か更新を続けていると、UFS でも起きているのを確認したのは、更に最近。

まず、bootstrap 用の clang が一度作られる。その後、toolchain 用に二度目の clang が作られる。そして、toolchain が出来た後に、本格的に buildworld が始まり三度目の clang が作られる。

buildworld をただ単に繰り返しただけで、その第二と第三の clang が必要も無いのに、再コンパイルされているのを突き止めたのが、二、三日前だった。

もう少し詳しく見てみようと思っていたところで、META_MODE: Fix 2nd build causing everything to rebuild due to changed CC. を発見。過度な再コンパイルに気づいていた人はいたみたいで、修正が CURRENT に入ったのを確認した。

これで、余計な clang の時間が大幅に減った。最近は機械が古くなってきているせいで、buildworld に四、五時間掛かることもあるので、かなり楽になる。なお、その大半の時間が clang に消費されていた。

ディレクトリ内のファイル数2014年01月11日 13時28分07秒

あるディレクトリ内にファイルが数万個だか、数十万個だかが作られていたらしい。どうなるかと言うと、ファイル操作が遅くなるのだ。ディレクトリの閲覧はもちろん、更新なども全てが遅くなる。

あまりにも増えてしまうと、シェルのコマンドラインの展開も出来なくなるし、削除をするのも色々と時間がかかり大変になる。今回の件では Solaris だったが、他も似たようなものだと思う。

実際に起こると結構見付けづらい問題だ。読み書きの速度が致命的な程に落ちたりするのだが、fsck などを含めてあれこれの診断も問題ないと出してくる。原因不明のディスクの速度低下があったら、find などで、ファイル構造を見るのは習慣にした方が良さそうだ。

大量メモリ搭載の FreeBSD の起動を早くする2013年11月25日 13時46分49秒

FreeBSD メーリングリストで見掛けた情報。FreeBSD の起動時に簡単なメモリの点検が入るため、起動が遅くなるそうだ。

hw.memtest.tests="0"

を /boot/loader.conf に記述すると、これを省くことが出来る。

32 GB のメモリを搭載している人達は早くなったそうだ。256 GB だと、これに二分程かかるらしい。古い BIOS に起因したものらしく amd64 等の新しいアーキテクチャには意味が無いそうだ。この雰囲気だと、将来的には amd64 では無効にされそうな感じ。

PC をイーサネットで直繋ぎ2013年11月24日 13時47分25秒

ノート型 PC を二台繋げて使うのは何年もやっている。FreeBSD が主なので、FreeBSD 同士がほとんどだが、NFS などを主にファイルの共有に使う。

無線だといちいち繋ぐ必要もなく便利だ。最近はそれなりの速度もでる。しかし、大型ファイルの転送にはやはり時間がかかってしまい、有線には勝てない。そこで、大きめの作業があるときは、いつもハブを取り出して繋いでいた。

ふと最近、わざわざハブの電源を入れて、各々一本ずつ計二本のケーブルを繋ぐのが面倒臭かった時があった。面倒臭いが早さが必要なので、とりあえず実験。PC 同士を普通のイーサネットケーブルでそのまま繋いでみた。いわゆるストレートケーブルである。するとそのまま使えてしまった。

昔々は、ストレートケーブルでは無くてクロスケーブルを使えだとか、ハブにもハブ同士の連結用と PC 用が分かれていた時代もあった。それが自動認識になったのも既に十年以上前。今では、PC 同士でも自動認識されるようだ。簡単に調べてみると GBE から自動認識の規格が入ったらしい。

FreeBSD の Java は openjdk2013年11月18日 13時15分33秒

久しぶりに NetBean で Java を使おうと思ったら、NetBean がインストールされていなかった。長いこと使っていなかったので消してしまっていたらしい。そして、Java もどの実装が現役なのだか。古いものだが四つ入っている。

% ls -d /usr/local/*jdk*
/usr/local/diablo-jdk1.5.0      /usr/local/jdk1.5.0
/usr/local/diablo-jdk1.6.0      /usr/local/jdk1.6.0

さて、make install で引っ張られてくるのは openjdk だった。FreeBSD Java Project: How To Install によると、OpenJDK が現在の公式の Java サポートみたいだ。

OpenJDK は以前の Java の様に自分でダウンロードをしておかなくても良いみたいだ。文句を言われてから取りに行こうと思って、おもむろに make install を叩いたが、そのまま無事に終了してしまった。

もう一つ。8.4 RELEASE 時の ports を使っているが、「Enable Legacy Debugging Support」を使って i386 上ではコンパイルエラーが発生した。これを無効にしてコンパイルを再度始めたところ、今度は問題なく終了できた。メモリが 4GB あると tmpfs を使って、OpenJDK をメモリ上だけでコンパイルとインストールできる。IO が省けて速くなる。

NetBeans 7.3 がデフォルトで、 NetBeans 6.1 の ports もあった。どちらともインストールするだけで動いた。ワークスペースの情報が引き継がれないみたいで、7.3 ではプロジェクトが空っぽだった。

前回次回

Solaris の fatal: relocation error:2013年10月04日 13時56分24秒

Solaris でプログラムを実行時に以下のエラーを残して急に落ちることがある。

ld.so.1: XXX fatal: relocation error: XXX: XXX: referenced symbol not found

XXX の部分は見付からなかった関数名だ。これが起こる原因はおそらくこの二つ。

まずは、リンク時と実行時のライブラリに不整合がある時になる。リンクされたバイナリを他のホストに移したが、同じライブラリが無かった場合に起こる。良く起こる場合としては、他所から共有ライブラリを使っているが、うっかり全てのホストにはインストールされていなかったなど。

そしてもう一つは、-lznodefs をリンカに渡して、解決仕切れなかったシンボルが存在したときに、起きる可能性がある。なぜ、起きる可能性があるかと遠回しな言い方をするかというと、実行時にこの関数を呼ばなければ、落ちることは無いからだ。

-lznodefs は名前から察する通り、解決仕切れないシンボルがあっても、プログラムのリンクを正しく終了できた事にしてしまうオプションだ。この事からも、本番環境に用いるプログラムでは、絶対に避けるべきオプションである。このオプションを使わないと、一つでも見付からないシンボルがあるとプログラムの生成は成功しない。

それではいつ使うかと言うと、やはり開発環境になる。共有ライブラリを用いたり、相互依存の醜いライブラリ群があると、いちいち再リンクをするのに時間と手間がかかる。開発環境で部分的な試験をしている時は、全部のコードが実行される事はほとんど無いので、業と呼ばれない部分を無視してしまうのだ。どうせ、本番環境では使わない邪道を用いて開発効率を上げているのだから、いちいち関係の無い細部に拘る必要もない。

しかし、時として見付からないシンボルがあって、実行時に落ちることがある。そんなときは、ldd -d を使って、どのシンボルが解決できていないかを探る。

-xs を用いずにデバッグシンボルを組み込むのを抑制する2013年08月04日 11時20分32秒

動作するプログラムを書くことを出来る人は大勢いるが、正しくコンパイルする事、効率的にコンパイル、リンクをする事が出来る人はほとんどいない。大部分の人達が、自分達が毎日、自分で何を行なっているかを把握していないのだ。知らず知らずのうちに、無駄を毎日の様に繰り返していることもしばしば。少しの変更で、大きな無駄を省けることも多々ある。一人で一割、二割の時間を有効に使えるようになるとしよう。それが、百人に及んだら事は重大だ。

Solaris には -xs というコンパイルオプションがある。これによりオブジェクトファイルなしに dbx でデバッグできるようになる。これを用いると、各々のオブジェクトファイルに入っているデバッグ情報が、実行ファイルへ全てコピーされるのだ。これが、リンクオプションで無いのは若干の不思議。

さて、このオプションを有効にするには -xs を指定する必要がある。これは、コードや中間生成物を共に移さない、本番系に有効なオプションだ。

つまり、このオプションを利用しないと、プログラムのサイズが大幅に小さくなる。元の一割やそれ以下の大きさにまでなってしまった等というのは日常茶飯事だ。

これを省くと、プログラムのリンクの時間が大幅に減る。デバッガの起動と再読み込みの時間も大きく減る。そして、ディスクの圧迫も回避となる。

もちろん、これを使わない不利益は、オブジェクトファイルが必要なこと。何かあった時に心配との事で、常に指定している組織も多い。

逆にいえば、一般的な開発環境では必要無い。そして、本番環境にオブジェクトファイルが無くても、core ファイルを持ってくれば、しっかりとデバッグが出来る。つまり、コードとオブジェクトファイルとしっかりと保持する運用体勢を確立していれば、用いなくても問題はない。または、本番用にのみ指定する運用でもいい。

成果物からは、弘法筆を選ばずの世界なのだが、その過程には、過ぎたるは猶及ばざるが如し、そして、労多くして功少なしの世界でもあるのだ。

なお、-xs は -xdebugformat=stabs を指定し、stabs 形式のデバッグ情報を用いる時に有効になる。-xdebugformat=dwarf で古い型の dwarf 形式を用いている場合には無意味だ。

AIX はある筋の情報によると stabs で、実行ファイル外にデバッグ情報を置くことは出来るが、dbx がオブジェクトファイルからその情報を読むことがまだ出来ない為、似たようなオプションは無いそうだ。