前回の対応からしばらく起きていなかったが、ちょっと前から再発するようになってきたので、いろいろ追加調査してみた結果をまとめる。

• unable to remap が rebase で解決しなかった時の話 - BOOLEANLABEL

rebaseall は setup.exe からインストールしたすべての DLL に一意な base を割り当てるため、大量の DLL を置いている場合は一部の DLL の base が負になってしまうことがある。

こうなると再度 rebaseall をしようとしても、rebase.exe が使用する cygiconv-2.dll や cyggcc_s-1.dll が unable to remap を吐いて、rebase 自体が起動できなくなってしまう。こうなってしまった場合はこれらの DLL を setup.exe から再ダウンロード→インストールすれば良い。

また、DLL は一旦ロードされると Windows の再起動までその base を使い続けるらしいため、rebase した結果は再起動しないと反映されない。

以上より、unable to remap の問題を解決するには以下のとおりにやれば良い。

while (何かしらの unable to map で cygwin shell が起動できない) {
  if (rebase が実行できない) {
    unable to remap になる cygiconv-2.dll or cyggcc_s-1.dll を再インストールする。
  }
  unable to remap が起きなくなるように -b を調整して、rebase を実行する。
  Windows を再起動する。
}

本家 ML でも先月あたりにここらへんの話で盛り上がってました。

• Two probable basing issues causing fork failures: (1) cygreadline7.dll h

実は 0.10.9 現在の cygport では想定するソースはアーカイブである必要があるという制限がある。具体的に言うと、hoge.c みたいな単体のソーステキストからパッケージにするには少し HACK が必要となる。

cygport のサブコマンド prep は内部の unpack() という関数で指定されたファイルの拡張子を基に解凍するコマンドを決定している。

# unpacks archives
unpack() {
local unpack_cmd;
local unpack_file_path;
local unpack_file_name;
local unpack_out;

for unpack_file_path
do
unpack_file_name=${unpack_file_path##*/};

if [ ! -f ${unpack_file_path} ]
then
error "Cannot find source package ${unpack_file_name}";
fi

# determine correct source decompression command
case ${unpack_file_path} in
*.asc|*.md5|*.sig|*.sign)  continue ;;
*.tar.bz2|*.tbz2|*.tar.bz|*.tbz) unpack_cmd="tar jxf" ;;
*.tar.gz|*.tgz|*.tar.Z) unpack_cmd="tar zxf" ;;
*.tar.lzma|*.tar.xz)
check_prog_req xz
unpack_cmd="tar --xz -xf"
;;
*.tar.lz)
check_prog_req lzip
unpack_cmd="tar -I lzip -xf"
;;
*.tar.lzo)
check_prog_req lzop
unpack_cmd="tar --lzop -xf"
;;
*.tar)  unpack_cmd="tar xf"  ;;
*.bz2)
unpack_cmd="bunzip2 -c";
unpack_out="${unpack_file_name%.bz2}";
;;
*.cpio.gz)
if check_prog bsdtar
then
unpack_cmd="bsdtar zxf";
else
unpack_cmd="__cpio_gz_extract";
fi
;;
*.gz)
unpack_cmd="gunzip -c";
unpack_out="${unpack_file_name%.gz}";
;;
*.gem)
unpack_cmd="__gem_extract";
;;
*.rar)
check_prog_req unrar;
unpack_cmd="unrar x -inul";
;;
*.src.rpm)
unpack_cmd="__srpm_extract";
;;
*.shar)
check_prog_req unshar;
unpack_cmd="unshar";
;;
*.xar)
check_prog_req xar;
unpack_cmd="xar -xf";
;;
*.zip|*.ZIP)
check_prog_req unzip;
unpack_cmd="unzip -oq";
;;
*.7z)
if check_prog 7zr
then
unpack_cmd="7zr x";
elif check_prog 7za
then
unpack_cmd="7za x";
else
error "p7zip is required to unpack this source package";
fi
;;
*) unpack_cmd="cp -t ${SRC_DIR}" ;;
esac

__step "Unpacking source ${unpack_file_name}";

if defined unpack_out
then
if ! ${unpack_cmd} ${unpack_file_path} > ${unpack_out}
then
error "${unpack_cmd} ${unpack_file_name} failed";
fi
else
if ! ${unpack_cmd} ${unpack_file_path}
then
error "${unpack_cmd} ${unpack_file_name} failed";
fi
fi
done
}

cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/cygport;a=blob_plain;f=lib/src_prep.cygpart;hb=HEAD

非アーカイブの場合は case 文の最後の条件にマッチすることになるため、cp でコピーをする処理に入るのだが、SRC_DIR はこのファイルを処理する前に別のアーカイブがアーカイブと同じ名前のルートディレクトリを含んでいて、それが既に展開されていることを仮定しているため、そのままではコピー先のディレクトリがないと言われてエラーになってしまう。

ちなみにアーカイブであっても、そのアーカイブがアーカイブ名と同じルートディレクトリを含まない場合は unpack() の後の cd で移動先のディレクトリがないと言われて、同様にエラーとなってしまう。

ここでコピー先となる SRC_DIR の初期値はアーカイブの名前から拡張子を覗いたものであるが、アーカイブの名前とアーカイブ内のルートディレクトリの名前が異なる場合はこの変数を .cygport ファイル内で再定義する必要がある。

アーカイブ内にルートディレクトリがある場合は SRC_DIR の再定義で対処できるが、ルートディレクトリがない場合やそもそもソーステキストのみしか配布されていない場合はルートディレクトリを用意する必要がある。

unpack() を見る限り外部から hook するのは難しいと思ったが、unpack_cmd を function にすることで対処できることに気づいた。

unzip()
{
        /usr/bin/unzip $* -d ${SRC_DIR}
}

cp()
{
        mkdir -p ${SRC_DIR}
        /usr/bin/cp $*
}

上記のようなコマンド名と同じ function を定義することで行儀の良くないアーカイブからでもパッケージにすることができる。*1

まとめ

if (ソースがアーカイブ) {
        if (アーカイブがルートディレクトリを含む) {
                そのままで良い
        } else {
                ダミーのルートディレクトリをつくってそこにアーカイブを展開させる
        }
} else { // ソーステキストのみ
        ダミーのルートディレクトリをつくってそこにコピーする
}

【追記】tar を再定義する場合は prep の場合のみ動作するようにする必要がある。

tar()
{
        case ${argv[${arg_n}]} in
                prep|unpack)
                        mkdir -p ${P}
                        cd ${P}
                ;;
        esac
        /usr/bin/tar $*
}

cygwin をそれなりに触っていると unable to remap というエラーに出会ったことがあると思います。

だいたい発生するのは自分でビルドした DLL を使うバイナリを起動した時でこういう場合には /bin/rebaseall はパッケージの DLL しか対象としないために自分でビルドした DLL をオプションで追加で指定してやる必要があります。

その方法については他の方の記事がぐぐれば出てくるので、そちらを参照してください。

• unable to remap - basyura’s blog
• Cygwinで”fatal error - unable to remap”と言われた: ここにはいないボクへの伝言
• 自ビルドしたパッケージの rebase - 壁は通り抜けられませんよ

自分の手元で起きた時も同じ問題だと思って rebase していたのですが、何故かある時から rebase しても解決できないようになりました。

いろいろ調べてみた結果、-b オプションでデフォルトのベースアドレスを 0x70000000 から小さい値に変えてみたら上手くいきました。*1

ところがしばらくすると -b オプションでも解決できなくなってしまいました。さらにぐぐってみたりしましたが、さすがにこれ以上は出てきませんでした...。

ふとエラーメッセージを見た感じで勝手に 32bit 空間が足りないんじゃないか？となんとなく思って Virtualbox に 64bit で OS から再インストールしたら、何故か発生しなくなりました。

704 名無しさん＠お腹いっぱい。 2011/10/04 (火) 18:04:54

Cygwin使っている人いますか？ その20 (UNIX板)

fork()地獄について

常識みたいだけど俺は知らなかったので書いとく

Vista以降ではrebaseallだけでなくpeflagsallってのも実行して、さらに

再起動する必要もあるみたいね

Vista以降にはセキュリティのためにASLRという機能があって、

これがcygwinのfork()エミュレーションと相性が悪いようだ

cygwinではrebaseallでDLLをロードするベースアドレスを衝突しないように

割り振っているけれども

ASLRでは、重要なデータや関数の位置が固定だと攻撃されやすいので

OSがランダムにリロケートするようになっている

PEにはASLRを許可するフラグ(DynamicBase)があって、

cygwinではpeflags.exeというツールでそれを弄れるようになっている

現在のPEのフラグは、objdump -p foo.exeとかやれば見れる

rebaseall同様、インストールされているexeやdllなどのフラグを全て書き換えるために

peflagsallというシェルスクリプトも提供されているので、それを使えってことの

ようだ

ただしこれらは/etc/setup以下から対象となるリストを取ってくるので、

野良ビルドしたもの(perlやpythonの拡張を後で入れたりした場合もありがち）は

含まれない

そういう環境ではスクリプトを弄るなどして自分で対処しないといけないと思う

ぶっちゃけWin7 64bitとかだと、死にかけのcygwinを無理やり使っているような

感じがしないでもない……

feezch: Cygwin使っている人いますか？ その20 過去ログ - 15ページ目

自分の手元の環境だと cygwin ports から DLL を持ってきていたりもしているため、もしかしたら base の割り当てを使い切っていたのかもしれないですね。

% head -5 /tmp/rebase.log
/usr/lib/virtuoso/hosting/wikiv.dll: new base = 1fba0000, new size = 50000
/usr/lib/virtuoso/hosting/wbxml2.dll: new base = 1fbf0000, new size = 10000
/usr/lib/virtuoso/hosting/mediawiki.dll: new base = 1fc00000, new size = 60000
/usr/lib/virtuoso/hosting/im.dll: new base = 1fc60000, new size = 10000
/usr/lib/virtuoso/hosting/creolewiki.dll: new base = 1fc70000, new size = 50000
%

去年の年末の話なんですけどね。（；＾ω＾）

ONKYO DLNA対応ワイヤレススピーカーシステム 15W+15W GX-W70HV(B) /ブラック

• 出版社/メーカー: オンキヨー
• 発売日: 2011/12/03
• メディア: Personal Computers
• クリック: 5回
• この商品を含むブログ (2件) を見る

なんとこのスピーカーはワイアレス再生ができるため、HDD の中の音楽をこのスピーカーから流せる。

ちなみに MacBook Air に List of UPnP AV media servers and clients - Wikipedia, the free encyclopedia に書いてあるソフトウェアを片っ端から入れてみたのだが、そもそもレンダラのリストにスピーカーが見えなかったり、やっと見えたと思って再生をさせたら、音量調節も停止もできずに一曲まるまる大音量で流れちゃったとかで、どうにもまともに使うことはできない。

それで今は VirtualBox にインストールしている Windows7 の Windows Media Player から操作するようにしている。*1

たぶん VirtualBox 側でネットワークをブリッジアダプタにしてあげないと見えないと思う。

あとは windows ヘルプに書いてあるとおりにすれば、上のスクショみたいに Windows Media Player の右上のあたりのメニューにスピーカーが見えるはずだから、それを選択するとリモート再生の小窓が起動するので、そいつで普通にコントロールできる。

探してみたら IO_Bit というのもありました。

• IO_Bit ￥ Package ￥ Openpear

string をがっつり渡して、integer などに変換するインタフェースっぽい。resource から string にするまでは関与しないということらしい。

以下、これらを踏まえてのインタフェースについての考察を述べてみる。

string ≒ byte[] ?

PHP は基本的に resource からの入出力データインタフェースが string である。そのため、バイナリデータを扱うためには string に対して pack / unpack や ord を使うのが定石っぽい。

PHP の文字列は言語仕様を見ると Java における byte[] に近い *1 とは言え、ストリームからのデータが string を経由することを利用者が意識しないといけないのはあんまりスマートじゃない気がするため、resource を渡したオブジェクトから直接 readXXX したら、その型のデータで得られるインタフェースが望ましいのではないかと思っている。(つまり java.io っぽいやつ)

エンディアン

バイナリデータを扱う場合に出てくるもう一つの問題がエンディアンで、これもライブラリによっていろいろ扱いが異なっている。

java.io ではビッグエンディアン決め打ちになっているし、上述の IO_Bit や php-reader では read メソッドの末尾に LE/BE という suffix があり、呼び出し毎に利用者が指定するようになっている。

せっかく LE/BE があるのはありがたいとは思うけど、逆にストリームの中で頻繁にエンディアンが変わる場合があるのかも気になる。コンストラクタでデフォルトのエンディアンを指定しておけばいいのではないかと感じる。

そろそろなんかちゃんとしたコードを公開しないとプログラマとして淘汰されるなあと強迫観念みたいなものを感じてる今日この頃です。

ここ一年くらい業務でログ集計系のコードを書くことが多く、その際に毎回、ログをパーズするためのプリミティブなファイルシステム関数の一連のコードをおまじないのようにコピペすることに抵抗があったため、java.io みたいなクラス群にまとめられないかなと思った。

既にこの要求を満たすものがあれば、それを使えばいいわけであるため、調べてみると当然ながら既に同じようなことを考えている人はいた。

• Phing
  • Internal Error ? Phing
• php-reader - The best PHP library for Object-Oriented media file information reading and writing. - Google Project Hosting
  • /trunk/src - php-reader - The best PHP library for Object-Oriented media file information reading and writing. - Google Project Hosting

前者はまさに java.io のインタフェースに沿っているなあという印象で、後者はバイナリデータ周りの実装がきちんと整っている。ただし、いずれも名前空間を使っていない。

とりあえずこの 2 つのいいとこどりをしたものを書いてみるというところから始めてみることにしてみようと思う。

ちなみに repo はつくってあるけど、中身はまだない。

• phozzil in phozzil - Gitorious