主に問題を解決する観点から GNU の素晴しい開発ツール群を始めとする 開発ツールについて書き並べてみました。
さすがに ls とかは省略。 シェル、仮想端末、 X 、エディタ、ブラウザ、メーラ、 make 、スクリプト言語なんかも当然として…
以下の他にも /proc (Linux では) に注目すると良い。
ps -auxww | grep
までエイリアス。
書いている最中に気付いたが、
psg() { ps -auxww | grep -E "(USER|$@)" }
とすると便利だ。
とても見やすくて良い。
killall で大体十分だと思う。
コマンド名指定で殺せる kill。
CPU 負荷などを見る。 top が top に来る。
素直に zsh 使っとけ。
find . -type f -name *.d -exec rm {} \;
と
rm **/*.d(.)
がだいたい等価。 前者も書けた方がコマンドライン引数の限界に達した時に なんとかなる分少し良いかもしれない。
updatedb でファイルシステム全体のデータベースを作っておく。 非常に高速にファイルシステム全体を走査できるので便利。 updatedb は cron などで定期的にしないと意味が無い。
私はこれしか知らないんですが、 ディストリビューション/OS ごとにこれに類するものがあるはず。
ソラでできなきゃ困ると思うこと。
パッケージ名から情報を得る。
rpm -qi binutils
パッケージ名からパッケージのリストを得る。
rpm -qil binutils
パッケージ名から依存関係を得る。
rpm -qiR binutils
ファイル名から上記を得る。
rpm -qif =nm # zsh
パッケージから上記を得る。
rpm -qip binutils*
パッケージ名一覧
rpm -qa
インストール
rpm -ihv binutils*
アンインストール
rpm -e binutils
ディストリビューションの rpm を全部集めたディレクトリで、
rpm -qipl * > rpms
などとしておくと便利かも。
.src.rpm は --rebuild, .spec は -ba 。
バイナリ関係の調べものに何かと役に立つものたち。 人様のソフトウェアで発生した問題の解決に役立つこともしばしば。
鵜飼さんの文章はとてもためになる。
シンボルの一覧を得るコマンド。 よくわからない undefined reference は このコマンドを使うことによって 適切なライブラリを発見できることが多い。
出力は、シンボルのアドレス、タイプ、シンボル名と出る。 タイプは U が未定義、 T が定義済み。 その他もだいたい定義済み。 小文字だとローカルなシンボル。
C++ のシンボルは mangling されていて意味がわからんので 後述の c++filt にパイプで渡す。
nm -o でファイル名も表示。これは欲しいシンボルを持つファイルを探す時に、
nm -o /usr/lib/*.a | grep finding_function
などとすればリンクすべきライブラリがわかる。
nm -l でソースの情報がある場合は そのシンボルの定義位置をファイル名と行数で表示。
意味のわからん C++ のシンボルを読みやすくする。
オブジェクトファイルの情報を得る。 私の場合たいていは逆アセしたいだけなので、
objdump -S hello
で事足りている。
とにかくいろんな情報を得られるので詳しくは man 。
objdump の友達。よく知らないので毎回 man を見ます。
アーカイブをいじるソフト。 たいていはたくさんの .o ファイルを .a ファイルに まとめるために使うと思う。
ar cru libhoge.a *.o
などと。その後は後述の ranlib を使う。
ar だけではダメな環境では
ranlib libhoge.a
とおまじないしておくと良い。 やっておいて損は無いので ar とセットで。
ar s と等価なので ar crus などとしても良いらしい。
アセンブラ。 gcc から呼ばれる。
リンカ。 gcc から呼ばれる。
バイナリから文字列を抽出します。 よくわからんファイルに使ったりします。
シンボル情報などを取り除いてバイナリを小さくしてくれます。
strip --strip-unneeded なら dll も安心。
プロファイラ。 gcc で -pg オプションをつけてコンパイルし、 実行した後に実行ファイルに対して
gprof hello
などと。
どこに書いたものやらとこのへんに。 LD_LIBRARY_PATH, LD_PRELOAD, LD_DEBUG あたりが便利か。
Linux では /lib/ld-linux.so.2 --list と同義、かな？ 実行ファイルや共有オブジェクトがどの共有オブジェクトに 依存しているかどうかを調べます。 すごく便利。
MacOSX では otool -L
第一引数を実行し、その際呼ばれたシステムコールを全て表示する。 -f で子プロセスもやってくれる。 -t, -tt で時間表示。 -c, -T で簡易プロファイル。
エラーメッセージ無しで落ちるものも strace してみると、
open("save/key.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
などという行が見つかったりしてああこのファイルが無いのだな、とわかる。
cygwin では今一つな結果が得られる。
hexdump -C が定番か。
echo password | ssh root@localhost ls
などとしてがっかりした場合は調べてみると良いかと。
オリジナルは Tcl らしいがスクリプト言語には大抵あるのでお好みで。
カバレッジを計るツール。 gcc で -fprofile-arcs -ftest-coverage を付けて、 後は gprof と似たようなもの。
デバッガ。詳しく記すには余白は狭すぎる。
r, where, b, c, p, n, s, l, i, x 位は知っていると良いのかな。
いよいよ本懐。
最適化するときは -O, -O2, -f* 、 デバッグする時は -g 、 警告は -W, -Wall あたりで、 プロファイリングは -pg 、 ansi な自信があれば -ansi -pedantic 。
gcc -v で何が起こっているか教えてくれるらしいが便利ではない。 以下のようなフェーズがある。
gcc -E でプリプロセスのみ行うことができる。 -dM もつければ定義されたマクロ一覧が得られる。
インクルードパスを通すのは -I 、 -DHOGE=1 で #define HOGE 1 と同様の効果。
デフォルトでは cc1 が行う。 cpp を使うように指定したりもできたはず。
gcc -c でコンパイル、アセンブルと行う。
コンパイルは cc1 の役目。 /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/cc1 などにあるはず。
他の言語なら cc1plus など、同じディレクトリにそれっぽいものがある。
アセンブルは as の役目。 binutils にある。
RTL というのはいろんなアーキテクチャを吸収する 抽象的なアセンブラ言語みたいなもの。 巨大な lisp 表記で見てもわけがわからない。 通常ファイルには書き出さないが、 -dr で吐き出せる。
この段階で既に言語に依存していないので、 言語実装者は gcc の最適化にかなり頼ることができるわけ。
途中の出力は -d? でいろいろと書き出せるが 依然として意味がわからない。
as などが読むためのアセンブラコードを一時ファイルに書き出す。 この部分は言語に依存していないので、 新しいハードウェアに対応させた時点でいろんな言語が使えるようになるし、 言語実装者にとっては色んな環境で動くようになる。 (ランタイムライブラリの環境依存を解決しなければならないが…)。
gcc ソース内の i386.md などを見ると頭が痛くなる。
特に無し。
/lib や /usr/lib なんかに ファイル libhoge.so.2 なんていうファイルがあったとして、 これをリンクする時は -lhoge 。 パスを増やす場合は -L 。
この時のエラーは慣れない人は苦労するようだ。 binutils を知れば自然と苦労しなくなるはず。
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。