Global Menu Bar for GNOME というが良い感じのようなので、インストールにチャレンジ。
Mac OS X のように、上部に配置された GNOME Panel が menu bar となる。
基本的には、GTK+ のアプリケーションのみが対象となるが、フォーカスされたアプリケーションのメニューへアクセスがしやすくなるような気がする。
GIMP とか Acrobat 9 とか。Firefox や Thunderbird はダメっぽい。
Mac OS X を利用している人などにはなじみ易いかと。
Global Menu Bar for GNOME
http://code.google.com/p/gnome2-globalmenu/
Vala - Compiler for the GObject type system なるものがあれば使うようだが、特にインストールされてなくてもよいみたい。
Vala - Compiler for the GObject type system
http://live.gnome.org/Vala
しかし、build できなかった orz
cofigure では、特に躓くこともなく。が、library の build で、ld のオプション一覧が出て error となってしまう。
まぁ、大体このパターンは GNU ld を想定したオプションが仕込まれており、/usr/ccs/bin/ld が呼び出されたため error となっていることが多い。
が、直接、ld を呼び出しているのではなく gcc を利用して link している。
経験上、そのような場合は、環境変数 PATH の先頭に GNU ld が配置されているパスを通し、再度 gmake を叩けば問題ないはずっ!
・・・
ダメだ orz
/usr/gnu/bin/ld を見てくれない orz
少し調べてみると、(´・ω・`)ショボーンな事実がわかった。
gcc を利用する場合、collect2 と呼ばれるユーティリティを利用し、プログラムの実行に必要となる様々な初期化関数などを呼び出す仕組みを付加する。
そんな collect2 は、ld を呼び出すようになっているが、OpenSolaris では、2 種類の ld が存在する。
/usr/ccs/bin/ld
/usr/gnu/bin/ld
目的を果たす役割としては、どちらも同一のものとなるが、オプションに互換性がないため、build するものによっては、利用する ld を切り替える必要がある。
Solaris や OpenSolaris 付属の gcc では、この切り替えがうまくいかない。
collect2 が ld コマンドを検索する際に下記の挙動を取る。
* GNU CC の検索ディレクトリに列挙されているディレクトリにある real-ld。
* 環境変数 PATH に列挙されているディレクトリにある real-ld。
* 指定されていれば、コンフィグレーションマクロ REAL_LD_FILE_NAME で指定されたファイル。
* GNU CC の検索ディレクトリにある ld。ただし、collect2 は自分自身を再帰的に実行することはない。
* PATH にある ld。
gcc がどんな検索 PATH を利用するかは、gcc -print-search-dirs で確認できる。
programs の最後に /usr/ccs/bin が入っている。
$ gcc -print-search-dirs
install: /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/
programs: =/usr/sfw/libexec/gcc/i386-pc-solaris2.11/3.4.3/:/usr/sfw/libexec/gcc/
i386-pc-solaris2.11/3.4.3/:/usr/sfw/libexec/gcc/i386-pc-solaris2.11/:/usr/sfw/li
b/gcc/i386-pc-solaris2.11/3.4.3/:/usr/sfw/lib/gcc/i386-pc-solaris2.11/:/usr/libe
xec/gcc/i386-pc-solaris2.11/3.4.3/:/usr/libexec/gcc/i386-pc-solaris2.11/:/usr/li
b/gcc/i386-pc-solaris2.11/3.4.3/:/usr/lib/gcc/i386-pc-solaris2.11/:/usr/sfw/lib/
gcc/i386-pc-solaris2.11/3.4.3/../../../../i386-pc-solaris2.11/bin/i386-pc-solari
s2.11/3.4.3/:/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../i386-pc-sola
ris2.11/bin/:/usr/ccs/bin/i386-pc-solaris2.11/3.4.3/:/usr/ccs/bin/
libraries: =/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/:/usr/lib/gcc/i386-pc-sol
aris2.11/3.4.3/:/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../i386-pc-s
olaris2.11/lib/i386-pc-solaris2.11/3.4.3/:/usr/sfw/lib/gcc/i386-pc-solaris2.11/3
.4.3/../../../../i386-pc-solaris2.11/lib/:/usr/sfw/lib/gcc/i386-pc-solaris2.11/3
.4.3/../../../i386-pc-solaris2.11/3.4.3/:/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.
4.3/../../../:/lib/i386-pc-solaris2.11/3.4.3/:/lib/:/usr/lib/i386-pc-solaris2.11
/3.4.3/:/usr/lib/
gcc のオプションで ld というコマンドがどのように検索されるか確認してみる。
$ gcc -print-file-name=ld/usr/ccs/bin/ld が呼び出されているのがわかる。
/usr/ccs/bin/ld
$ gcc -print-prog-name=ld
/usr/ccs/bin/ld
さらに、PATH が影響していることも懸念し、環境変数 PATH を unset (ksh) し確認してみる。
$ unset PATHやっぱり /usr/ccs/bin/ld が呼ばれる。
$ echo $PATH
$ /usr/sfw/bin/gcc -print-file-name=ld
/usr/ccs/bin/ld
$ /usr/sfw/bin/gcc -print-prog-name=ld
/usr/ccs/bin/ld
PATH に /usr/gnu/bin/ を追加して確認してみる。
$ PATH=/usr/gnu/bin; export PATH
$ echo $PATH
/usr/gnu/bin
$ /usr/sfw/bin/gcc -print-file-name=ld
/usr/ccs/bin/ld
$ /usr/sfw/bin/gcc -print-prog-name=ld
/usr/ccs/bin/ld
ん? PATH は見てくれず、/usr/ccs/bin/ld 決め打ちっぽい悪寒・・・なんでだろう?
collect2 に strings をかけてみると・・・
$ cd /usr/sfw/libexec/gcc/i386-pc-solaris2.11/3.4.3/
$ strings collect2 | grep ld
/usr/lib/ld.so.1
ldout
/usr/ccs/bin/ld
ld_file_name = %s
ld returned %d exit status
real-ld
collect-ld
いた。
いやがった。抱えてやがった。/usr/ccs/bin/ld を!
このように埋め込まれていると、/usr/ccs/bin/ld が存在する限り必ず /usr/ccs/bin/ld を見に行くっぽい。
むむむ。
OpenSolaris では、/usr/ccs/bin/ld が /usr/bin/ld に移動したのですが、/usr/ccs/bin/ls は互換性のために sym link として残っています。
まずは、この /usr/ccs/bin/ld を無くしてみます。無くすといっても、別な名前に remove してもいですし link なので元ファイルがわかっていれば消してしまってもいいです :)
PATH も unset してみると、
$ /usr/sfw/bin/gcc -print-file-name=ld
/usr/lib/ld
$ /usr/sfw/bin/gcc -print-prog-name=ld
ld
$ /usr/sfw/bin/gcc -print-file-name=kazus
kazus
おっと、なんかイイ感じに崩壊してきましたね。
/usr/lib/ld はディレクトリですしおすし。
-print-prog-name=ld のほうは、なんか、与えられた文字列そのまま返してますね。
gcc が持つ検索 PATH に /usr/gnu/bin が入っていないため ld コマンドは見つかりません。
この状態で、collect2 はどう振る舞うか見てみると、
PATH は unset され、/usr/ccs/bin/ld もなくなると、collect2 は呼び出すべき linker
を見付けられないため下記のメッセージを出力します。
$ cd /usr/sfw/libexec/gcc/i386-pc-solaris2.11/3.4.3
$ ./collect2 --help
collect2: cannot find `ld'
/usr/gnu/bin に PATH を通し、ld を確認してみると /usr/gnu/bin/ld が呼び出されていることがわかりました。
$ PATH=/usr/gnu/bin; export PATH
$ echo $PATH
/usr/gnu/bin
$ cd /usr/sfw/libexec/gcc/i386-pc-solaris2.11/3.4.3
$ ./collect2 -v
collect2 version 3.4.3 (csl-sol210-3_4-20050802) (i386 System V Release 4)
/usr/gnu/bin/ld -v
GNU ld (GNU Binutils) 2.19
一度、unset PATH を実行して、/usr/bin に PATH を通してみる。
$ PATH=/usr/bin; export PATH
$ echo $PATH
/usr/bin
$ ./collect2 -V
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1683
gcc 検索用 PATH は無視され、環境変数 PATH に設定されたパスを検索対象と切り替え、ld コマンドを呼び出し利用するようになる。
なるほど。
というわけで、Global Menu Bar for GNOME を build するときに一時的に /usr/ccs/bin/ld を削除!Ψ(`∀´)Ψ
無事に build できました(´∀`*)
configure は、こんな感じ。applet が /usr/libexec にインストールされるのがアレですが。。。
$ env CFLAGS=-O3 ./configure --prefix=/usr --with-gconf-schema-file-dir=/etc/gconf
まぁ、美しくはないですが、この件については gcc を自分で build したらどうなるかとか確認したい。
gcc -v で、configure 時のオプションを確認することがでいるのですが、--with-ld=/usr/ccs/bin/ld と --without-gnu-ld が鍵を握っているんじゃないかと思っていたり・・・
$ /usr/sfw/bin/gcc -v
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs
Configured with: /builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,f77,objc --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-20050802)

参考:
http://www.sra.co.jp/wingnut/gcc/gcc-j.html#Collect2

