海野秀之（うんのひでゆき）の外部記憶
Twitter (twilog) / RSS / アンテナ / ぶくま
実は、おうちの環境にはまだ cutter が入ってませんでした。
GLib いれたり、lntltool いれたり、xgettext いれたりして、 configure は通ったんだが、make でこけた。
cut-test-suite.c: In function `collect_backtrace': cut-test-suite.c:339: error: invalid lvalue in assignment cut-test-suite.c:341: error: invalid lvalue in assignment
該当箇所は、
339: stdout = pseudo_stdout; 340: g_on_error_stack_trace(cut_get_cutter_command_path()); 341: stdout = original_stdout;
ふむふむ。stdout に代入するのは、まかりならん、と。
よくわからんけど、dup とか dup2 とか使うのかなぁ。
よくわからんので、あとで。
"ld: fatal: relocations remain against allocatable but non-writable sections" は、もしかしたらポピュラーなハマりどころなのかも知れないと思い直して、再挑戦。
上の３つや、それらの組み合わせをいろいろ試してみたけど、改善せず。
もー、あれだ。relocation なんてするからいかんのだと、binutils を -fpic オプションつきでソースコンパイルしなおしてみる。
そうして、もういっかい cutter の ./configure してみたら、まだダメなんだけど、 ld の吐くエラーの数はだいぶへった。
気を良くして、./configure のときにも -fpic が付くようにすれば良いのではないかと思い、
% CFLAGS=-fpic ./configure
とやったら、いけたよ！やったぁ！
gmake -s check すると、いくつか fail していたりするんだけど、
% cutter/cutter --fatal-failures test
FE
1) SystemError: cut-test-context-error-quark:0
失敗を致命的な問題として扱い、異常終了しています。
2) Failure: test_fail
always fail
fixtures/test-context/test-relative-path.c:10: cut_assert_always_fail(): cut_fail("always fail")
fixtures/test-context/test-relative-path.c:16: test_fail(): cut_assert_always_fail()
Finished in 0.006546 seconds (total: 0.000000 seconds)
1 test(s), 0 assertion(s), 1 failure(s), 0 error(s), 0 pending(s), 0 omission(s), 0 notification(s)
0% passed
always fail とか、わざと fail させているんだったら、問題ないのかな。
あと、途中で test がハングしたみたいになるんだけど、もしかしたら、遅いだけなのかも。 あんまり時間がとれないので、あとで確認する。
あ、test/run-test.sh は solaris の /bin/sh では動かないスクリプトだったので、 She-bang を #!/bin/bash に書き換えて使用。
これで動きますか？<br># ここだとパッチが壊れちゃいそうな気がしますが。<br><br>Index: cutter/cut-test-suite.c<br>===================================================================<br>--- cutter/cut-test-suite.c (revision 2807)<br>+++ cutter/cut-test-suite.c (working copy)<br>@@ -321,25 +321,18 @@<br> collect_backtrace (void)<br> {<br> int fds[2];<br>- FILE *original_stdout, *pseudo_stdout;<br>+ int original_stdout_fileno;<br> <br> if (pipe(fds) == -1) {<br> perror("unable to open pipe for collecting stack trace");<br> return;<br> }<br> <br>- original_stdout = stdout;<br>- pseudo_stdout = fdopen(fds[1], "w");<br>- if (!pseudo_stdout) {<br>- perror("unable to open FILE for pipe");<br>- close(fds[0]);<br>- close(fds[1]);<br>- return;<br>- }<br>- stdout = pseudo_stdout;<br>+ original_stdout_fileno = dup(STDOUT_FILENO);<br>+ dup2(STDOUT_FILENO, fds[1]);<br> g_on_error_stack_trace(cut_get_cutter_command_path());<br>- stdout = original_stdout;<br>- fclose(pseudo_stdout);<br>+ dup2(STDOUT_FILENO, original_stdout_fileno);<br>+ close(original_stdout_fileno);<br> <br> read_backtrace(fds[0]);<br>
ひえぇ、今日自分でやろうと思ってたんですが。。。<br># kou さんに催促するために書いたわけじゃないんです（汗<br><br>会社の環境 (Linux) だと、書き換えなくても動いちゃうので、<br>うちに帰ってから確かめます。<br><br># stdout の切り替えについては、SPARC Solaris (職場にごろごろ転がってる) で確認することは可能かなぁ。<br><br>とにかく、やってみます。
会社の環境がどうだ、こうだと、あんまりここで書かない方がいいのかも知れないな。
kou さん、<br><br>> これで動きますか？ <br><br>dup2 の第１引数と第２引数が逆ってことはないですか？<br> <br>↓こうかな、と思ったんですが：<br><br>static void<br>collect_backtrace (void)<br>{<br> int fds[2];<br> int original_stdout_fileno;<br><br> if (pipe(fds) == -1) {<br> perror("unable to open pipe for collecting stack trace");<br> return;<br> }<br><br> original_stdout_fileno = dup(STDOUT_FILENO);<br> dup2(fds[1], STDOUT_FILENO);<br> g_on_error_stack_trace(cut_get_cutter_command_path());<br> dup2(original_stdout_fileno, STDOUT_FILENO);<br> close(original_stdout_fileno);<br><br> read_backtrace(fds[0]);<br><br> close(fds[0]);<br> close(fds[1]);<br>}
そして、これをなおしたら、別のエラーが！<br><br>Undefined first referenced<br> symbol in file<br>collect_symbols_bfd ../cutter/.libs/libcutter.so<br>cut_loader_support_attribute_bfd ../cutter/.libs/libcutter.so<br>ld: fatal: Symbol referencing errors. No output written to .libs/cutter<br>collect2: ld returned 1 exit status<br><br>うちの環境では、HAVE_BFD_H が yes、HAVE_LIBBFD が no になるという変なことになってしまっていた（xstrerror は libbfd になくて、libibrerty にある？）のが原因のようでした。<br><br>これは、config.h を直接編集して、HAVE_BFD_H の define をコメントアウトしてやることで対処。<br><br>これで、cutter の build に成功したと思います！<br><br>ふー、あんまりメンテしてない solaris 10 とか使っていると、みょうな苦労しますね。
Cutter の self test (make check) で、けっこうエラーしているみたい。<br><br>ううむ、Solaris 10 x86 だからなのか、僕んとこの環境がいい加減なのか。。。<br><br>ひとまず、放っておきたいところ。<br># 普段の開発環境 (CentOS 5) では問題なく動いているので。
はい、そうでした。（trunkにはコミット済み） < dup<br><br>libibrertyにあるときでもうまく動くように作ってあったはずなんですが。。。<br>config.logとか見せてもらえますか？-lbfdとか-libertyでのリンクに失敗していると思うのですが。<br>（放っておくということなので、とりあえず見てみたいだけ）<br><br>たぶん、テストは共有ライブラリのシンボルを見つけられなくて失敗しているんだと思います。<br>このあたりは、やっぱり、BFDが使えないと厳しいです。<br><br><br>あ、HAVE_BFD_Hだけがyesのときでもビルドできるようにしておきました。
いろいろ、すみません ＞ kou さん。<br><br>おうちの x86 solaris は、むかしにインストールしたっきりかまってなかったものなので、<br>なんだか、見られるのがはずかしかったりして。。。<br><br>もういちど、最新の (trunk top?) cutter でチャレンジしてみて、だめだったら config.log をお見せしたいと思います。<br><br>おうちでは、まだ使ってませんが、もう、すでに Cutter なしでは生きていけないカラダになりつつあるかも。<br><br>すごい便利、かつ、楽しい。助かってます！
気に入ってもらえてよかったです。 :)
>config.logとか見せてもらえますか？-lbfdとか-libertyでのリンクに失敗していると思うのですが。<br>>（放っておくということなので、とりあえず見てみたいだけ） <br><br>一応、見えるところにおいておきました。: http://uhideyuki.sakura.ne.jp/files2009/config.log<br><br>あきらかに、僕んとこの環境に問題があるっぽいので、捨て置いてください。<br><br>↓このへんとか。あやしすぎる＞うちの環境<br><br>configure:22757: checking for xstrerror in -liberty<br>configure:22792: gcc -o conftest -g -O2 -Wall -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wcast-align -shared conftest.c -liberty >&5<br>Text relocation remains referenced<br> against symbol offset in file<br><unknown> 0x1f /usr/local/lib/gcc/i386-pc-solaris2.10/3.4.6/../../../libiberty.a(xstrerror.o)<br>xstrerror_buf 0x24 /usr/local/lib/gcc/i386-pc-solaris2.10/3.4.6/../../../libiberty.a(xstrerror.o)<br>xstrerror_buf 0x2e /usr/local/lib/gcc/i386-pc-solaris2.10/3.4.6/../../../libiberty.a(xstrerror.o)<br>xstrerror 0xd /var/tmp//ccWOwUbf.o<br>strerror 0xc /usr/local/lib/gcc/i386-pc-solaris2.10/3.4.6/../../../libiberty.a(xstrerror.o)<br>sprintf 0x29 /usr/local/lib/gcc/i386-pc-solaris2.10/3.4.6/../../../libiberty.a(xstrerror.o)<br>ld: fatal: relocations remain against allocatable but non-writable sections
もしかして、Sun の ld (/usr/ccs/bin/ld) じゃなくて、<br>binutils に入っている the GNU linker (/usr/local/bin/ld に入った) を<br>つかえってことなのかな。<br><br>そんな気がしてきた。
あ、たぶん、-mimpure-textオプションをつけるといけます。<br><br>ところで、唐突で、これには関係ないんですが、どこでCutterを見つけたんですか？？？<br>マイナーなのにどうやって見つけてくれたのかなぁと思いまして。。。
> あ、たぶん、-mimpure-textオプションをつけるといけます。<br><br>そうなんだ。やってみます。<br><br>> どこでCutterを見つけたんですか？？？ <br><br>ここです： http://pub.cozmixng.org/~hiki/programming/?CUnit<br><br>この春、C で新たにそれなりの規模のプログラムを書きはじめようと思いまして、<br>単体テストフレームワークを使ってみようと思いたち、<br>C の xUnit といえば、CUnit かなぁといろいろ情報収集していたところに、<br>「CUnitよりもCutterの方がおすすめです」と書いてあったのを見た、と。<br><br>「そっか、おすすめかぁ」みたいな感じで（素直）。
あ、あと、CUnit にはいろいろ不便な点があるらしく、<br>世の中には、いくつか改良版があるらしいというのも、ざらっとした調査の感触として得ていました。<br><br>それもあって、「CUnitよりもCutterの方がおすすめです」は、きっと本当なんだろうなぁと思いました。<br><br>あんまり論理的な推論じゃない気がしますが。。。
あ、ずっと前に私が書いたやつだ。。。<br>しかも、そのCUnitはうんのさんが情報収集しようとしていたCUnitじゃないんですよね。<br><br>なんにせよ、Cutterにたどりついてもらえてよかったです。 ;-)
そうなのかー。<br><br>ま、わたしは結果的に幸せになったので、なにも問題ないです（笑。
先日Cutter 1.0.7をリリースしたのですが、ELFとか共有ライブラリを自前でパースするようにしました。<br><br>SolarisもELFのようなので、BFDなしでもビルドできるようになったかもしれません。<br>elf.hがあるならいける気がします。
ご連絡ありがとうございます。<br><br>家の x86 Solais 10 にはすでにインストール済なのですが、<br>会社でも使っている（というか、会社で使っている）ので、<br>会社にある SPARC Solaris マシンで試してみます。<br># いまは、デスクトップの Linux マシン上で使用。<br><br>いまとりあえず、ダウンロードして ./configure したら・・・<br><br>checking for mach-o/loader.h... no<br>checking elf.h usability... yes<br>checking elf.h presence... yes<br>checking for elf.h... yes<br>checking for pkg-config... /usr/local/bin/pkg-config<br>checking pkg-config is at least version 0.16... yes<br>checking for GLIB - version >= 2.16.0... no<br>*** Could not run GLIB test program, checking why...<br>*** The test program failed to compile or link. See the file config.log for the<br>*** exact error that occured. This usually means GLIB is incorrectly installed.<br>configure: error: GLib >= 2.16.0 required.<br><br>ああ、そうでした、そうでした。<br><br>ちょっと今すぐには時間がとれないのですが、インストールしてみて結果はおしらせします！
おおっ！このページに書いてある通りにやってみれば良いのですね。<br>http://cutter.sourceforge.net/reference/ja/install-to-others.html
SPARC Solaris 10 でコンパイル、インストールできました。<br>期待どおりコンパイルできているかどうか、興味がおありかもしれないので、config.log を置いておきます。<br><br>http://uhideyuki.sakura.ne.jp/files2009/config_sparc_sol10.log<br><br>LANG=C gmake -s check の結果も一応：<br><br>http://uhideyuki.sakura.ne.jp/files2009/cutter_sparc_sol10_check.log<br><br>なんか、コケてるようにも見えるんですが。。。<br><br>しかし、これで、今書いているコードの確認を、x86_64 Linux, SPARC Solaris の両方で行えるようになりました！<br>どちらでも問題なく動いています。<br><br>Linux, Solaris など、異なる環境で確認すると、自分が移植性の無いコードを書いてしまっていないかの良いチェックになるんですよね。
おぉ！<br>ほんとに動いている！！！<br><br>アサーションの数が同じなので、ちゃんとすべてのテストがパスしていると思います。<br>po/以下でのmake checkの失敗はmake update-poをし忘れていたことが原因なので、そんなに大きな問題ではないです。<br><br>Solarisでやるときに注意することはgmakeを使うことぐらいですか？（Solaris用のインストールドキュメントを書こうかと思いまして。。。）<br>あ、あと、test/run-test.shがbashじゃないとダメ、というのはexportのせいだけですか？他にもまずいところがあったりします？<br><br><br>> Linux, Solaris など、異なる環境で確認すると、自分が移植性の無いコードを書いてしまっていないかの良いチェックになるんですよね。 <br>そうなんですよ！<br>あと、使っているライブラリのバージョン違いで挙動が変わってしまったときとか、自動化されたテストがあると、そういうところがすぐにわかって便利ですよね〜
> Solarisでやるときに注意することはgmakeを使うことぐらいですか？<br><br>だと思います。<br>わたしは、もともと gmake を使っているので、なにも問題を感じませんでした。<br><br>glibc だけじゃなく、libintl とか gettext とかも足りなくていれたくらい。<br><br>> bashじゃないとダメ、というのはexportのせいだけですか？<br><br>ええ。<br><br> export HOGE=fuga<br><br>を、すべて<br><br> export HOGE; HOGE=fuga<br><br>に書き換えたら動きました。<br><br># 一行めを #!/bin/bash に書き換える方が楽なので、最初そうしましたが。。。<br><br>> 自動化されたテストがあると、そういうところがすぐにわかって便利ですよね〜 <br><br>テストが自動化されていない環境は、もう想像するのも恐いです。
言い忘れてましたが、Solaris でも動くように対応してくださって、ありがとうございます ＞ kouさん<br><br>とってもありがたいです！
喜んでもらえてよかったです！<br><br>test/run-test.shは動くように直しました！たぶん。。。<br><br>Solarisで教えて欲しいことがあるのですが。。。<br>インストールドキュメントを書きはじめてみました。<br>https://cutter.svn.sourceforge.net/svnroot/cutter/cutter/trunk/doc/install-to-solaris.rd.ja<br>GLibとかgettextとか他のソフトウェアのインストール方法を書くのが面倒なので、できれば「パッケージを利用してインストール！」みたいな感じですっ飛ばしたいのです。<br>（パッケージでインストールの方がインストールする人も楽だと思いますし。）<br><br>Solarisでパッケージというとどうやってインストールするものなのでしょうか？<br><br>って、今、気づいたのですが、Solaris 10って2005年リリースなんですね。古い。。。<br>そりゃ、Cutterを動かすのは大変か。。。
> 「パッケージを利用してインストール！」<br><br>「正式」な手段は無いんじゃないかと思いますが、<br>http://www.sunfreeware.com/ で配布されているパッケージを pkgadd するのがお手軽な手段として知られていると思います。<br><br>が、glib は 2.14.1 しかないので、自分でビルドしないとだめです。<br>http://www.sunfreeware.com/programlistsparc10.html#glib<br><br>glib をビルドする際、lntltool, gnu gettext なども必要だったので、それらは、このサイトからパッケージをとってきて、<br>pkgadd しました。<br><br>wget ftp://ftp.sunfreeware.com/pub/freeware/sparc/10/intltool-0.40.3-sol10-sparc-local.gz<br>gzip -d intltool-0.40.3-sol10-sparc-local.gz<br>pkgadd -d ./intltool-0.40.3-sol10-sparc-local.gz<br><br>って感じ。<br><br>Glib 以外は、足りなければパッケージをとってきてインストールしろで良いと思います。<br><br>Glib は、残念ながら自前でビルドしないとだめでした。<br>普通に ./configure, (g)make, (g)make install で良さそうなものですが、<br>私の手元では、./configure --with-libiconv=gnu としないとうまくいきませんでした。これは、環境に依存すると思う（のと、自分の環境が普遍的だという自信はない）ので、<br><br>gconvert.c:55:2: #error GNU libiconv not in use but included iconv.h is from libiconv<br>gconvert.c: In function `g_iconv':<br>gconvert.c:177: 警告: 互換性のないポインタ型からの引数 2 個の `libiconv' を渡しますです<br><br>./configure; gmake で、こういうエラーがでたら、--with-libiconv=gnu を試してみよう、くらいですかね。<br><br>> って、今、気づいたのですが、Solaris 10って2005年リリースなんですね。古い。。。 <br><br>１０年保証なんですよ！とか言ってみたりして。。。
↓ご参考までに、ちょっと kou さんの真似（？）して書いてみました。<br><br>Solaris で cutter 使うひとが増えたら、わたしもうれしいです。<br>----<br>Cutterを動かすためにはGLib 2.16以降が必要です。<br><br>http://www.sunfreeware.com/ には、GLib 2.16 のパッケージが未だ無いため（2009 年 5 月現在）、<br>Glib は自分でコンパイル、インストールしなければなりません。<br><br>% mkdir -p ~/src<br>% cd ~/src<br>% wget http://ftp.gnome.org/pub/GNOME/sources/glib/2.20/glib-2.20.1.tar.gz<br>% tar xvfz glib-2.20.1.tar.gz<br>% cd glib-2.20.1<br>% ./configure<br>% make<br>% make install<br><br>intltool. gnu gettext 等が足りない場合は、それらもインストールする必要があります。<br>これらは、http://www.sunfreeware.com/ からパッケージを持ってきて用いることが可能です。<br><br>例：<br>% wget ftp://ftp.sunfreeware.com/pub/freeware/sparc/10/intltool-0.40.3-sol10-sparc-local.gz<br>% gzip -d intltool-0.40.3-sol10-sparc-local.gz<br>% pkgadd -d ./intltool-0.40.3-sol10-sparc-local.gz <br><br>なお、環境によっては、以下のようなメッセージとともに Glib のビルドがエラーしてしまうことが<br>あるかもしれません。<br><br>gconvert.c:55:2: #error GNU libiconv not in use but included iconv.h is from libiconv<br>gconvert.c: In function `g_iconv':<br>gconvert.c:177: warning: passing arg 2 of `libiconv' from incompatible pointer type<br><br>この場合には、./configure --with-libiconv=gnu のように gnu libiconv の使用を明示する<br>オプションを用いてください。
ありがとうございます！<br>うんのさんのやつをベースに完成させました！<br><br>なるべく問題に当たらないように、GNU libiconvは必ず指定するような書き方にしました。
すてきだっ。<br>日本人かつ Solaris ユーザ（ちょーマイノリティ）にもやさしいっ（涙