brandelf?
doh...@hf.rim.or.jp
たら作れるんでしょうか?
○
昔, ある筐体で 4.0R を動かしていました. これが壊れたので別のマシンにハー
ドディスクをそのまま載せたところ, X 以外はそこそこ快適に動いてくれました.
が, 流石にモノクロで 640x480 はキツイので (16 色だと文句をいうアプリケー
ションが結構ある), X (4.3) を入れようとしたところいくつかのシンボルが
未定義で動作してくれませんでした.
cvsup で 4.0R->4.8R は make も通らず. 4.7R は make buildworld までは通
るのですが, /bin/* のコマンドが軒並「brandelf で指定しろ」といって動作
してくれませんでした (/bin/test とかも).
ドキュメントも「make world してからカーネル作れ」というのもあれば「カー
ネル作ってから make world しろ」というのもありさっぱりです.
仕事柄コンパイラは色々触ります. それでも /usr/local/* 以外は触っていな
いつもりなのですが, PATH を /sbin:/bin:/usr/sbin:/usr/bin に限定しても
駄目でした.
一体こういうバイナリはどうやって出来るのでしょうか?
# 今そのマシンで書いてます. 適当に make world した後ネットワーク関係が
# invalid system call とか出るようになった辺りで make installkernel し
# て再起動して今また make world 中です. 返事は Cc: でメイルでももらえ
# ると嬉しいかも.
# 4.0R からは cvsup 自身もまともに取ってこれなかったので適当なバイナリ
# を持ってきて使ってます.
# この辺破綻してない?
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp
Koji Mori
> ドキュメントも「make world してからカーネル作れ」というのもあれば「カー
> ネル作ってから make world しろ」というのもありさっぱりです.
古いバージョンに対して書かれたドキュメントを参照してしまったとか
ではないでしょうか。
4.x のソースにある UPDATING には
make buildworld
make buildkernel
make installkernel
reboot
make installworld
mergemaster
reboot
とか書いてあると思います。buildkernel では作成に使用する環境が
buildworld で作られるものを使用したりするので順番は絶対です。
installworld の過程では古い kernel で動作しないバイナリに置き換えられる
ケースがあるので、それ以前に新しい kernel での起動が必要です。
他にも注意する点があったりしますから、4.0R -> 4.8R という大きな
upgrade をする時には一通り読んだ方が良いと思います。
# 4.0R -> 4.8R が大きいかどうかは FreeBSD を追いかけていない
# 人にとっては自明じゃないといわれればそのとおりですが、
# それならなおさらのこと UPDATING は読むべきです
# (4.7R->4.8R という小さな upgrade であっても)。
> 一体こういうバイナリはどうやって出来るのでしょうか?
関係あるかどうかはわかりませんが、UPDATING にはこんな記述もあります。
20000706:
Binutils were updated. In order to build a kernel after this
date, you must follow the updating procedure for building
kernels exactly as presented here. You may be able to get away
with doing it the old way, but if it breaks, make sure that you've
tried the "To build a kernel" section with a fresh /usr/obj
first.
> # 4.0R からは cvsup 自身もまともに取ってこれなかったので適当なバイナリ
> # を持ってきて使ってます.
古い cvsup を使っていたりしないでしょうか。古い cvsup は例の10億秒問題
とかでファイルの新旧の判定を間違えるので、多くの CVSUP server では
接続を拒否するようになっていると思います。
--
森 浩二 (MORI Kouji)
(株)淺沼組 技術研究所
E-mail: mo...@tri.asanuma.co.jp
doh...@hf.rim.or.jp
In article <80k7azu...@kurishna.tri.asanuma.co.jp>
Koji Mori <mo...@tri.asanuma.co.jp> writes:
> make buildworld
4.0R→4.8R はまずこれも通らなかったような気がします. 存在しないヘッダ
ファイルを何かが参照してたような.
で, 結局 4.7R を持ってきて
> make buildworld
> make buildkernel
> make installkernel
> reboot
> make installworld
> mergemaster
> reboot
こういう流れでやったつもりなんですけど (余分な buildworld は入ったかも)
C++ で書かれたプログラムが軒並落ちます.
| $ gperf
| /usr/libexec/ld-elf.so.1: gperf: Undefined symbol "__get_eh_context"
| $ groff
| /usr/libexec/ld-elf.so.1: groff: Undefined symbol "__builtin_vec_new"
で, これって
| 20000124:
| The default way that virtual tables in our default C++
| compiler has changed. We used to use THUNKS for virtual
| inheritance. Unfortunately there are bugs that The GCC
| developers thought would be fixed in GCC 2.95. However it
| isn't.
|
| After this change existing applications written in C++ may
| give errors like below when you try to run them:
|
| /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol "__vt_7filebuf"
|
| The only fix is to rebuild the application and any C++
| libraries used.
これでしょうか? …なんかちょっと違う気がするなぁ. もちっと悩んでみます.
doh...@hf.rim.or.jp
package とかでない gcc をソースコードから /usr/local/bin/* 辺りへイン
ストールする場合, 次のような手順を踏むと思います.
1) システムの cc (または gcc) で最適化をオフにして stage1 コンパイラ
を作る.
2) stage1 コンパイラで適当に最適化して stage2 コンパイラを作る.
3) 2 と同じコンパイルオプションで stage2 コンパイラを使って stage3
コンパイラを作る.
4) stage2/stage3 コンパイラを比較して同じならインストール.
ここでシステムの cc のバージョンが違えば (たとえ同じ最適化オプションを
選んだとしても) stage1 コンパイラは stage2/stage3 コンパイラと異なるも
のになるはずです.
で, UPDATES にある方法だと思い切りこれを端折っちゃってる気がするんです
けど. 先の gperf が動作しなかったのは, 古いコンパイラでコンパイルした
ライブラリを使っていたのが原因のようです (brandelf も同じかも).
gperf は buildworld にも用いられるので以降同じ環境で buildworld も通ら
なくなりますが, この状態で /usr/obj/* にある gperf は動作します. つま
り
古いコンパイラでコンパイルした古い gperf
古いコンパイラでコンパイルした新しい gperf (動作しない)
新しいコンパイラでコンパイルした新しい gperf
てなことになって普通にインストールされるのは二番目になっちゃうような.
このことが
The only fix is to rebuild the application and any C++
libraries used.
なんでしょうけど, これって C++ に限らずもう一度やっておかないと最悪シ
ステムの挙動が直前のシステムのコンパイラのバージョンに依存しちゃいます
よね?
Koji Mori
> 古いコンパイラでコンパイルした古い gperf
> 古いコンパイラでコンパイルした新しい gperf (動作しない)
> 新しいコンパイラでコンパイルした新しい gperf
>
> てなことになって普通にインストールされるのは二番目になっちゃうような.
ええと、そんなはずは。と私が言っても信憑性はないので、
Makefile を読んでもらった方が手っ取り早いかもしれないです。
確か
1. 古いコンパイラ(1)を使い、古い環境で動く新しいコンパイラ(2)を作成する
2. (2)を使って新しいライブラリ群(3)を作成する
3. (2)と(3)を使って新しい環境で動く全てのバイナリ(4)を作成する
だったと思います。(だいぶはしょってますが)
# (4) は新しい環境でしか動くことが保証されませんので、
# installworld する前に installkernel + reboot が必須。
doh...@hf.rim.or.jp
Koji Mori <mo...@tri.asanuma.co.jp> writes:
> ええと、そんなはずは。と私が言っても信憑性はないので、
> Makefile を読んでもらった方が手っ取り早いかもしれないです。
あー, そうなんですか. なるほど.
一応再度順序を確かめながら行ったところ gperf は動くようになりました.
といっても 4.7R っぽい環境で 4.7R をコンパイルし直したに過ぎないわけで
すが.
んでも相変わらず groff が動かない….
| $ groff
| /usr/libexec/ld-elf.so.1: groff: Undefined symbol "__builtin_vec_new"
皆さんのところではそのままで動いてるんですよね? うーん…. 私のところで
はこうなっちゃいます.
| $ cat t.cc
| #include <iostream>
|
| int
| main()
| {
| std::cout << "hello, world\n";
| return 0;
| }
| $ /usr/bin/c++ -o t t.cc
| $ ./t
| /usr/libexec/ld-elf.so.1: Undefined symbol "cout" referenced from COPY relocation in t
| $ /usr/bin/c++ -static -o t t.cc
| $ ./t
| hello, world
# 「X も動いたし良しとするか」とも思ったけどマニュアル読めないのはイタイ.
Koji Mori
doh...@hf.rim.or.jp () writes:
> | $ ./t
> | /usr/libexec/ld-elf.so.1: Undefined symbol "cout" referenced from COPY relocation in t
うちの 4.8R で試すと ldd t で /usr/lib/libstdc++.so.3 が表示されますし、
objdump -T /usr/lib/libstdc++.so.3 で cout があるのが確認できます。
# libstdc++ が壊れてるんですかね?
doh...@hf.rim.or.jp
Koji Mori <mo...@tri.asanuma.co.jp> writes:
> うちの 4.8R で試すと ldd t で /usr/lib/libstdc++.so.3 が表示されますし、
> objdump -T /usr/lib/libstdc++.so.3 で cout があるのが確認できます。
というヒントをいただいたので試してみたところ
| $ ldconfig -elf -r |grep stdc
| 44:-lstdc++.3 => /usr/lib/libstdc++.so.3
| 90:-lstdc++.2 => /usr/lib/compat/libstdc++.so.2
| 189:-lstdc++.3 => /usr/local/lib/libstdc++.so.3
| $ LD_LIBRARY_PATH= /usr/bin/c++ -o t t.cc
| $ ldd t
| t:
| libstdc++.so.3 => /usr/local/lib/libstdc++.so.3 (0x28066000)
| libm.so.2 => /usr/lib/libm.so.2 (0x280ab000)
| libc.so.4 => /usr/lib/libc.so.4 (0x280c6000)
ということで何故か /usr/local/lib を見に行ってしまいます. ふと build
時の環境変数が影響しているかもしれないと思ってその辺りに気をつけて
build したところうまくいくようになりました. ありがとうございます.
# 後は /usr/bin/g++ と /usr/local/bin/g++ とかの同居方法を考えないと….