元祖ワシ的日記

どうも現状のportsだと、glib20は /usr/local/include/iconv.hがあれば使わないようにconfigureしても絶対それをincludeしちゃうようです。なら gnuのiconvを削除すればいいんじゃね？と思ったわけですが、libiconvを pkg remove -fで削除したら（当然ながら）いろいろなモノが動かなくなり、それでもまぁもっかいビルドすればいいかと思ってたんですが、portsそのものがコンパイルできなくなるという状態に(pythonとか動かないので）。これはいかんと、いうことで　zfs rollbackで戻しました。いずれiconvは削除できるのは削除するという方向にして、 とりあえずは /usr/local/include/iconv.hだけを別名に renameして glib20をごまかしてやることにしました。（あとで忘れそうだな

この状態で

portmaster -a -w -d

としたら、大部分がリビルドできるように。たまに出るエラーは手動で修正。大抵は依存関係の問題なんで、先に別なほうをビルドしちゃえばOKですが（めんどうくさいw

全部まっさらにして入れ直したほうが早かったかなー？しかしFreeBSD8から継ぎ足して使ってきた秘伝の・・・（略

いくつか標準から外れたものがあるようだ。とりあえず cvsは消えてくれてサンキューだが、digは無いと困るので入れた。

portsのリコンパイルはportmasterにお任せなんですが、それでもiconv関連で以下のようなメッセージが出て、

error: GNU libiconv not in use but included iconv.h is from libiconv

エラーで止まって悩みました。

これ以前別のプロジェクトでもハマったんだよな。おそらくconstがついてるか否かとかそういう（些細な）問題だったような記憶があるけど、これは古い何かと何かがかち合って、何かと何かのiconv.hの宣言がかみ合ってないのか？まずはググるが、適切な回答みつからず。しゃーないから自分で調べる

/usr/ports/devel/glib20のMakefile

を眺めると

ICONV_LIBというのが定義されていると、 configureに  --with-libiconv=gnuが渡されるようである。エラーで止まったあとに workの下で ./config.statusしてみると

# ./config.status --config
'--enable-static' '--disable-gtk-doc' '--with-html-dir=/usr/local/share/doc' '--disable-man' '--without-xml-catalog' '--with-pcre=system' '--disable-fam' '--disable-dtrace' '--with-libiconv=native' '--disable-modular-tests' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=x86_64-portbld-freebsd10.0' 'build_alias=x86_64-portbld-freebsd10.0' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing' 'LDFLAGS= -L/usr/local/lib' 'CPPFLAGS=-I/usr/local/include -DLIBICONV_PLUG' 'CPP=cpp' 'CXX=c++' 'CXXFLAGS=-O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -DLIBICONV_PLUG' 'PKG_CONFIG=pkgconf' 'PYTHON=/usr/local/bin/python2.7'

と、nativeなiconvを使おうとしてるので、これが効いていないっぽい。devel/glib20/Makefileを強引に gnuを使うように書き換えたらちゃんとコンパイルが通った。

つまるところ、nativeな iconvを使おうとしてるのに /usr/local/include/iconv.h をincludeしているのがよくないのであろう。ここまではわかった。

コンパイラのインクルードパスを見る順番という問題な気もするが、iconvを全削除して、portsをリビルドするとうまくいくような気もする？それはそれでいろいろ別な問題が発生するような気がするが、さてどちらの対処でいくかべきか？

放置していたFreeBSD RELEASE-10へのアプグレードですが、OSはほぼ問題なく移行できました。まぁ問題はその後の設定なんですけどね。

• jailの起動でいろいろ言われるので、警告どおり jail.confに書き換える
• パッケージ管理システムがpkgへ移行したのでpkg2ngでコンバート（なにやら色々と嫌な感じの警告が沢山でてる）

とりあえずここまで。あとlinux関係のモジュールでいくつかエラーが出てたのう・・・

9.1まではこちらの記事にあるこちらのパッチが適用できたのですが、9.2からは数ヶ所rejectされるようになってしまいました(ちなみに /usr/ports/net/stf-6rd-kmodから入れても同じようなことになるような感じ）

なので手動でセコセコ直す作業が発生。疲れた～。 一応sakuraのVPSではちゃんと動いているようです。 疲れたついでに9.2用のパッチをここにおいときます。

前は/etc/rc.confに

jail_sysvipc_allow="YES"

としとけば動いたんですが、9.2からは

jail_jail171_parameters="allow.sysvipc=1"

のように書かないとダメっぽい。これ以上詳しくは追ってない・・

cannot start jailと出て起動しなく。手動では起動するので/etc/rc.d/jailが何か変更になったぽい。で追っていくとIPv6の指定の仕方が不味いということに気がつきました。パラメータのIPのリストをみてIPv4のときはip4.addr, IPv6のときはip6.addrで指定するように変わったようです。で、/etc/rc.confには以下のようにかいていたのですが

jail_jail171_hostname="jail171.jail"
jail_jail171_ip="192.168.253.171,2400:XXXX:100::192.168.253.171"
jail_jail171_rootdir="/jails/jail171"
jail_jail171_procfs_enable="YES"
jail_jail171_devfs_enable="YES"
jail_jail171_exec_start="/bin/sh /etc/rc"
jail_jail171_exec_stop="/bin/sh /etc/rc.suhtdown"
jail_jail171_mount_enable="YES"

2400:XXXX:100::192.168.253.171が *.*.*.*にマッチしてしまいIPv4のアドレスだと思われてしまうようです。故に全部:で区切って書けば問題なさげです。あるいは/etc/rc.d/jailの以下の部分:

    # Identify type {inet,inet6}.
    case "${_addr}" in
    *\.*\.*\.*)     _type="inet" ;;
    *:*)            _type="inet6" ;;
    *)              warn "jail_extract_address: type not identified"
                    ;;
    esac

これを

    # Identify type {inet,inet6}.
    case "${_addr}" in
    *:*)            _type="inet6" ;;
    *\.*\.*\.*)     _type="inet" ;;
    *)              warn "jail_extract_address: type not identified"
                    ;;
    esac

とするとよいようです。

起動して何かしようとすると、

VirtualBox cannnot talk to klauncher Not connected to D-Bus server. FreeBSD

のようなエラーが出て動かないという。まさかファイルのダイアログが開けなくて動かないとか・・・うーん。

で、検索してみると、このあたりがズバリそれのようです。

[Solved] DBus running but not working - The FreeBSD Forums

上のリンクを読んでみると分かる通り解決方法はdbusのダウングレード。何か負けてるような気もしますが、詳細を追ってる時間がないのでオイラもそれに習いダウングレードで解決を目指すことにしました。負け犬。

ダウングレードは古いソースをもってきて自分でmakeしてinstallすればいいんですけど、どうせならportsで管理しておきたいところ。そこで、 portdowngadeとportmasterでダウングレードすることにしました。portdowngradeは /usr/ports/ports-mgmt/portdowngrade/にあるのであらかじめ installしておきます。

ちなみにこのブログ書いてる時点でdbusのバージョンは 1.6.12 です。このバージョンがinstallされていると仮定します。

# portdowngrade devel/dbus

とやるとdbusの更新履歴がずらずらと出てきます。見ると

r312209

が 1.4系の最終バージョンのようなので、このときのportsのディレクトリをチェックアウトしてきます。

# cd /home/hoge
# portdowngrade devel/dbus 312209

このチェックアウトは/usr/portsの下とかでやらないほうがよいでしょう。自分のホームディレクトリとかでやります。するとdbusというディレクトリにr281729のportsのdbusのディレクトリが現れます。

その後

# portmaster -w -o <dbusを展開したディレクトリ> /var/db/pkg/dbus-1.6.12

とやります。これでdbusを再起動したら大体動いているようです。もっとも他のdbusを使うpkgはdbusのバージョンが1.6.12だと思ってるから何か予期せぬ問題が発生するやもしれませんけどね・・・まぁそんときはそんときということで。とりあえず今は何事もなく動いているようです。

/usr/obj/arm.armv6/PATH/tmp/usr/bin
(PATHはコンパイルしたソースのパスが入るので適宜修正）

MRuby::CrossBuild.new('armv6') do |conf|
  toolchain :gcc  
  conf.cc do |cc|
    cc.command = "/usr/obj/arm.armv6/PATH/tmp/usr/bin/cc"
  end
  conf.linker do |linker|
    linker.command = "/usr/obj/arm.armv6/PATH/tmp/usr/bin/cc"
  end 
  conf.archiver do |archiver|
    archiver.command = "/usr/obj/arm.armv6/PATH/tmp/usr/bin/gnu-ar"
  end
end