そういえば snapshot.debian.net は fsijでのdisk 4.3Tがあふれていて、2009年4月あたりのぶんをとりそこねていた。5月最初に気付いて手元では残しているが、次をなんとかしないといけないかんじ。fsijには24台のディスクがはいるやつがあるけどディスクそのものをどう調達しようかなあというところで検討中。全部そろってないとだめで、全部買うと50万くらい? 寄付を募ってみるかとかいう話にもなりそう。などなど
その後の月例会では、chromium/linuxの話をしてみた。普段は Ubuntu/Hardy相当の会社のマシンで開発してたりするけど、前日あたりから手元のvaio Z(Debian/sid)でも開発環境をととのえてみたらいろいろはまった。以下そのまとめ。
とりあえずLinux用のBuild Instructionに従えばよい
vaio zはamd64 archなので64bit用のセットアップが必要(V8あたりが64bitサポートがないため)。
ただしDebian/sidだとbuild/install-build-deps.shはそのままうごかない。まずUbuntuチェックをはずす。そしてlibdirectfb-1.2-0をlib_listに加える必要がある。いくつか/usr/lib32で*.soがないので適当にシンボリックリンクをはる必要もある。はらないとgcc -m32でリンクする時にライブラリみつけるのに失敗して64bit用のをリンクしようとしてできないというエラーになる。
cd /usr/lib32 ln -s libpangoft2-1.0.so.0 libpangoft2-1.0.so ln -s libgthread-2.0.so.0 libgthread-2.0.so ln -s libgio-2.0.so.0 libgito-2.0 ln -s libgconf-2.so.4 libgconf-2.so ln -s libdirectfb-1.2.so.0 libdirectfb-1.2.soまあこれは install-build-deps.shのバグなのかも?
必要なパッケージをインストールしたら depot_toolsをcheckout
$ svn co \ http://src.chromium.org/svn/trunk/tools/depot_toolsそしてチェックアウトされたdepot_toolsにPATHを通す。ここに含まれるgclientやgclといったツールを使って開発する。
depot_toolsを入手したらgclientでrepositoryからチェックアウト
$ gclient config \ http://src.chromium.org/svn/trunk/src $ gclient syncこれでsrcディレクトリ以下にチェックアウトされる
hammerでビルド
$ cd src/build $ hammer app../sconbuild/Debug/chrome が実行ファイル。しかしそのままだと一部フォントのレンダリングが変…
調べた結果、これが原因
Pango-WARNING **: \ /usr/lib/pango/1.6.0/modules/pango-basic-fc.so: \ wrong ELF class: ELFCLASS64これは install-build-deps.sh でやってるhackが原因というか。このscript、i386で必要なdebをapt-getして、/lib、/usr/lib 以下のをそれぞれ /lib32、/usr/lib32 になるようにパッケージしなおしてインストールするということをしてます。だいたい問題ないけどmoduleのロードパスなどはそのまま/usr/lib以下だったりして、そっちは64bit *.soなのでmodule loadに失敗しているということに。
結局次のような *.so をLD_PRELOADしてやればよいかんじに
/**
* Copyright (c) 2009 Fumitoshi Ukai
* All rights reserved.
*
* Fix module load path from /lib,/usr/lib to /lib32,/usr/lib32
*
* $ gcc -m32 -fPIC -o module_fix.o -c module_fix.c
* $ gcc -m32 -shared -o module_fix.so module_fix.o -ldl
* $ LD_PRELOAD=`pwd`/module_fix.so /path/to/chromium/sconsbuild/Debug/chrome
*/
#define _GNU_SOURCE 1
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
void *dlopen(const char *filename, int flag) {
void *(*orig_func)(const char *, int) =
dlsym(RTLD_NEXT, "dlopen");
char *new_filename = NULL;
if (strncmp(filename, "/usr/lib/",
strlen("/usr/lib/")) == 0) {
int len = strlen(filename) + 3;
new_filename = malloc(len);
snprintf(new_filename, len, "/usr/lib32/%s",
filename + strlen("/usr/lib/"));
} else if (strncmp(filename, "/lib/",
strlen("/lib/")) == 0) {
int len = strlen(filename) + 3;
new_filename = malloc(len);
snprintf(new_filename, len, "/lib32/%s",
filename + strlen("/lib/"));
}
printf("dlopen: %s\n",
new_filename ? new_filename : filename);
void *p = orig_func(
new_filename ? new_filename : filename, flag);
if (new_filename)
free(new_filename);
return p;
}
これで一部のfontが変なのはなおるが、resolveできなくてweb browseできない問題が。 これは/etc/nsswitch.confの次の設定のせいっぽい
hosts: files mdns4_minimal [NOTFOUND=return] \ dns mdns4この設定だとgetaddrinfo(3)がEAI_NONAMEをかえすのでresolveできないという結果に。 結局mdns4あたりの設定をはずして次のようにしてやればよさげ
hosts: files dns
ディスカッションでは renderer process の sandboxはどういうのがあれば幸せになれるだろうかでもりあがった。chromiumではLinux Sandboxingあたりに情報が。ここにかいてある通り現状では linuxでは no sandboxです。(No sandbox - Where we are currently. A compromised renderer can still get at your X socket so it fails all requrements. )
現状では IMEサポートがまだなので実用的ではないです。
ただ現在鋭意開発中なので、ここに書いてあることはすぐにobsoleteになる可能性があります。詳しくはdev.chromium.orgをみてください。
