2010年11月13日土曜日

EDIROL FA-66 ドライバのインストールでハマッた

FA-66 ドライバの再インストールをしようとして、ちょっとハマッたので、備忘録として書き残す。

検証環境
  • Windows Vista Business (64ビット) SP2
  • EDIROL FA-66
  • IEEE1394 拡張ボード(Texas Instruments 製チップ)

インストールしたバージョンは、EDIROL FA-66 Driver Ver.1.0.6 for Windows Vista 64ビット版 (2008.03.25 公開)(FA66_Vis64Drv106J.zip)。

再インストールなので、zip ファイルを解凍し、その中の UnInstall.exe を実行する。
再起動後、setup.exe を実行する。手順通りに進め、FA-66 の電源を入れるところまで進める。
ここからが重要。
FA-66 の電源を入れる前に、FA-66 背面の「SAMPLE RATE」スイッチを”44.1”または”48”に設定する。”96”または”192”に設定しておくと、「FA-66 を使用する準備をしています。しばらくお待ちください。」から進まなくなる。場合によっては、強制リセットで再起動してしまう。
マニュアルにも、インストール手順にもそれらしい記述は無いので、環境依存なのか・・・

2010年11月1日月曜日

MeCab を MinGW-w64 でビルド。ついでに、Java バインディングもビルド

MeCab をビルドしたくなった。ついでに Java からも使いたい。そしてそれは、64ビット版でなくてはならない。

環境


MinGW 環境は、これまで色々ビルドしているので、他にも必要なライブラリなどがあるかもしれないが、今回やった手順しか書かないので注意。

libiconv のビルド
tar zxvf libiconv-1.13.1.tar.gz
cd libiconv-1.13.1
./configure --prefix=/mingw --enable-static --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32
make
make install
libiconv のビルドは、スンナリできた。

MeCab 用 IPA 辞書のビルド
tar zxvf mecab-ipadic-2.7.0-20070801.tar.gz
cd mecab-ipadic-2.7.0-20070801
./configure --prefix=/mingw --with-charset=utf-8
make

MeCab のビルド
パッチファイル(MeCab_0.98_MinGW.patch)については後述する。
以下の手順でビルドすると、 libgcc_s_sjlj-1.dll が実行時に必要となる。このファイルは MinGWディレクトリの ”x86_64-w64-mingw32/bin/”に入っている。パスを通すか、実行ファイルと同じディレクトリにコピーしておく必要がある。依存を無くそうと悶絶してみたが、私のレベルでは、どうしてもできなかった。ちなみに私のレベルは5である。スライムぐらいには勝てる・・・・
tar zxvf /f/Archive/mecab-0.98.tar.gz
cd mecab-0.98
patch -p0 < MeCab_0.98_MinGW.patch
CPPFLAGS='-I/mingw/include' LIBS=-liconv ./configure --prefix=/mingw --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --enable-utf8-only --with-charset=utf8
make

MeCab のパッチファイル
このパッチファイルこそが、今回の血と汗と涙の結晶。若干の説明をおこなう。

【config.h.in】
49 行目
#undef HAVE_PTHREAD_H
↓
//#undef HAVE_PTHREAD_H
これは、pthread を利用しないようにするため。インストールされていなければいらない。うちの環境では、以前 pthread をインストールしていて、それを使うと MeCab.exe 実行して、1行入力後に固まるようなので、利用しないようにした。pthread を利用しない場合は、WindowsAPI の同様の機能を利用するようだ。

【src/feature_index.cpp】
311 行目
case 't':  os_ << (size_t)path->rnode->char_type;     break;
↓
case 't':  os_ << static_cast<unsigned int>((size_t)path->rnode->char_type);     break;
あいまいなキャストだったので、修正。これが正しいのかは神のみぞ知る・・・

【src/libmecab.cpp】
53 行目
#ifdef __cplusplus
↓
#if defined(__cplusplus) && !defined(__MINGW32__)

65 行目
#ifdef __cplusplus
↓
#if defined(__cplusplus) && !defined(__MINGW32__)
ここは、偉大なる先人の知恵。

【src/Makefile.in】
260 行目
INCLUDES = -DDIC_VERSION=$(DIC_VERSION) $(MECAB_WITHOUT_SHARE_DIC) $(MECAB_WITHOUT_MUTEX_LOCK) $(MECAB_USE_UTF8_ONLY) -DMECAB_DEFAULT_RC="\"$(MECAB_DEFAULT_RC)\""
↓
INCLUDES = -DDIC_VERSION=$(DIC_VERSION) $(MECAB_WITHOUT_SHARE_DIC) $(MECAB_WITHOUT_MUTEX_LOCK) $(MECAB_USE_UTF8_ONLY) -DMECAB_DEFAULT_RC='"$(MECAB_DEFAULT_RC)"'
ここの修正は、苦肉の策。どうもうちの環境では、変数の展開に問題があるらしく、思ったようにならない(バックスラッシュだらけになり、バックスラッシュの個数も1個足りないとか・・・)。よって、この値を利用している、src/utils.cpp を修正した。ここは、コンパイルが通るようにしただけで、理想の対処とは程遠い。

【src/mecab.h】
131 行目
#ifdef _WIN32
↓
#if defined(_WIN32) && !defined(__MINGW32__)

254 行目
#ifndef SIWG
↓
#ifndef SWIG
ここも、偉大なる先人の知恵。

【src/utils.cpp】
282 行目
if (rcfile.empty()) rcfile = MECAB_DEFAULT_RC;
↓
if (rcfile.empty()) rcfile = "C:\\appli\\MeCab_utf8\\etc\\mecabrc";
ここは、mecabrc ファイル格納デフォルトディレクトリをハードコーディングした。各自の環境に合わせて、変更する必要がある。
ソースを読むと、ホームディレクトリの”.mecabrc”か、MECABRC 環境変数の値か、レジストリ”HKEY_LOCAL_MACHINE\software\mecab”の”mecabrc”の値か、レジストリ”HKEY_CURRENT_USER\software\mecab”の”mecabrc”の値か、MeCab.dll と同じディレクトリの”mecabrc”を探すらしい。それでも見つからないときにこの値を利用するようだ。
本来的には、Make の変数展開を何とかするべきなんだろうが、LV5 ではなんとも・・・

【src/writer.cpp】
236 行目
case 'L': *os << std::strlen(sentence); break;
↓
case 'L': *os << static_cast<unsigned int>(std::strlen(sentence)); break;
あいまいなキャストってコンパイラに怒られたので、適当にキャストしてみた(おいっ)。いいのかなぁいいのかなぁ。

MeCab Java バインディングのビルド
tar zxvf mecab-java-0.98.tar.gz
cd mecab-java-0.98

先ほどビルドした MeCab から必要なファイルを Java バインディングのディレクトリにコピーする。
cp ../mecab-0.98/src/mecab.h .
cp ../mecab-0.98/src/.libs/libmecab.a .

Java の bin ディレクトリをパスに追加
export PATH=/c/appli/Java/jdk1.6/bin:$PATH

Makefile を修正
TARGET=MeCab
JAVAC=javac
JAVA=java
JAR=jar
CXX=c++
INCLUDE=c:/appli/Java/jdk1.6/include

PACKAGE=org/chasen/mecab

LIBS=-L. -L/mingw/lib -lmecab -liconv
INC=-I$(INCLUDE) -I$(INCLUDE)/win32

all:
    $(CXX) -O3 -c -fpic $(TARGET)_wrap.cxx  $(INC)
    $(CXX) -shared -static $(TARGET)_wrap.o -o $(TARGET).dll $(LIBS)
    $(JAVAC) -encoding utf-8 $(PACKAGE)/*.java
    $(JAVAC) -encoding utf-8 test.java
    $(JAR) cfv $(TARGET).jar $(PACKAGE)/*.class

test:
    LD_LIBRARY_PATH=. MECABRC=./mecabrc $(JAVA) -Djava.file.encoding=euc-jp test

clean:
    rm -fr *.jar *.o *.dll *.class $(PACKAGE)/*.class
    
cleanall:
    rm -fr $(TARGET).java *.cxx


java のコンソール出力が文字化けするので、ファイルにログを吐いておく。、
make > build.log 2>&1

出来上がったもののテストをしてみる。
設定ファイルを作る
cp ../mecab-0.98/mecabrc .

コピーした mecabrc を修正する。辞書ディレクトリを指定する部分に、先ほどビルドした辞書のディレクトリを設定する。
dicdir =  ..\mecab-ipadic-2.7.0-20070801

テストを実施
コンソール出力は、文字化けするのでファイルに吐いて確かめる。
make test > test.log 2>&1

テスト結果
LD_LIBRARY_PATH=. MECABRC=./mecabrc java -Djava.file.encoding=euc-jp test
0.98
太郎 名詞,固有名詞,人名,名,*,*,太郎,タロウ,タロー
は 助詞,係助詞,*,*,*,*,は,ハ,ワ
二郎 名詞,固有名詞,人名,名,*,*,二郎,ジロウ,ジロー
に 助詞,格助詞,一般,*,*,*,に,ニ,ニ
この 連体詞,*,*,*,*,*,この,コノ,コノ
本 名詞,一般,*,*,*,*,本,ホン,ホン
を 助詞,格助詞,一般,*,*,*,を,ヲ,ヲ
渡し 動詞,自立,*,*,五段・サ行,連用形,渡す,ワタシ,ワタシ
た 助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
。 記号,句点,*,*,*,*,。,。,。
EOS

 BOS/EOS,*,*,*,*,*,*,*,*
EOS

ちなみに、辞書を指定せずに実行すると、以下のようなログが出力される。
LD_LIBRARY_PATH=. MECABRC=./mecabrc java -Djava.file.encoding=euc-jp test
0.98
Exception in thread "main" java.lang.RuntimeException: tagger.cpp(151) [load_dictionary_resource(param)] param.cpp(71) [ifs] no such file or directory: ./mecabrc
    at org.chasen.mecab.MeCabJNI.new_Tagger__SWIG_1(Native Method)
    at org.chasen.mecab.Tagger.<init>(Tagger.java:128)
    at test.main(test.java:17)
make: *** [test] Error 1

文字コードの違う辞書を指定してしまうと、文字が化け化けになる。指定しているつもりが無くとも、MeCab をインストーラーでインストールしたことがあると、レジストリに設定ファイルの場所が設定されてしまうので、こういう事態に陥りやすいので注意。

MeCab の設定ファイルの指定方法は複数あるが、今回は、環境変数で指定してある。DLL と同じディレクトリに入れる方法もあるのだが、レジストリでの指定より優先順位が低いので、環境によって問題がある。

これでめでたく Java から MeCab を利用することが出来る。
いや、長かった・・・・この手順も長いが、実はかなり遠回りをしてしまい、実際にはここに書かれていない作業を延々としてしまった。GLib コンパイルしたりとか、gettext コンパイルしたりとか・・・
まあ、いろんな意味でレベルは上がった。怪我の功名というやつですな。次は Python バインディングか・・・・

2010年10月31日日曜日

Eclipse CDT と MinGW (64ビット環境)で JNI のデバッグ

ふと、Eclipse で JNI 呼び出し DLL のデバッグがしたくなった。
つまんない事で嵌ったので、備忘録として書いておく。

検証環境:
  • Windows Vista Business (64ビット) SP2
  • Eclipse classic 3.6.1(64ビット) Build id: M20100909-0800
  • Eclipse CDT 7.0.1.201009141542
  • JDK 1.6.0_16(64ビット)
  • MinGW-w64 (mingw-w64-bin_i686-mingw_20100702_sezero.zip)
  • GDB (x86_64-w64-mingw32-gdb-7.1.90.20100730.zip)
  • Make (make-3.82-20100827.zip)

以前に、CDT の設定をして、うまく動いていたと思ったのに、久しぶりに Eclipse を起動したら、MinGW を認識してくれなった。CDT のアップデートを行ったからだろうか?
しょうがないので、サポート外Toolchain から MinGW を選択した。path に MinGW/bin が設定されていれば、デフォルトの include ディレクトリや lib ディレクトリは自動的に設定されるようだ。
まあ、ここら辺の調査は宿題としておこう。

まあ、何事にも共通するが、初めてやるものは、最小限の状態から試すことが大事。

JNI で Java ソースと C++ のソースを作成済みとする。
プロジェクトは、Java と C++ で分ける必要がある。Java プロジェクトには、JNI インターフェースを作成するソースを格納。これは、そのままテスト駆動用とする。C++ プロジェクトには、JNI インターフェースのヘッダファイルと、ヘッダに定義されている関数の実装を記述したソースを格納。

C++ プロジェクトの設定

C++ プロジェクトのプロパティを開く
「C/C++ Build」-「Settings」で「Tool Settings」タブを開く

「GCC C++ Compiler」で以下を設定
  • 「Preprocessor」の「Defined symbols(-D)」に”_JNI_IMPLEMENTATION_”を追加。これは、jni.h の中に定義されている。未設定でも動いたが、ヘッダの該当箇所あたりに記述してあるメソッドを利用するときは設定する必要があるのかもしれない。
  • 「Includes」の「Include paths(-I)」に JDK をインストールしたディレクトリの include と include/win32 を追加。
  • 「Debugging」の「Debug Level」を”Default(-g)”に設定。

「All options」を見るとこんな感じ
-D_JNI_IMPLEMENTATION_ -I"C:\appli\Java\jdk1.6\include" -I"C:\appli\Java\jdk1.6\include\win32" -O2 -g -Wall -c -fmessage-length=0


「MinGW C++ Linker」で以下を設定
  • 「Miscellaneous」の「Linker flags」に”-static”と”--kill-at”を追加。static は、静的リンクをしたい場合につける。kill-at はシンボルの後ろに @ を付けたくないときに付ける。両方とも無くてもかまわない。たぶん。
  • 「Shared Library Settings」の「Shared(-shared)」チェックボックスをチェック

「All options」を見るとこんな感じ
-static --kill-at -shared


「Settings」画面の「Build Artifact」タブで以下を設定
  • 「Artifact Type」を”Shared Library”を設定。ただ、この設定がどこに影響があるのか不明。
  • 「Artifact name」を”${ProjName}”に設定。出力ファイルのベースファイル名になる。
  • 「Artifact extension」を”dll”に設定。出力ファイルの拡張子になる
  • 「Output prefix」を空にする。出力ファイル名の先頭に付加される。

以上で C++ プロジェクトへの設定は完了
ビルドすると、Default ディレクトリに dll ファイルが生成されるはず。

Java デバッグの設定
  • DLL 読み込みのために以下のいずれかのように DLL のディレクトリを設定する。
    • 「VM arguments」に”-Djava.library.path=../hello-jni/Default”のように指定。
    • 「Environment」に”PATH”を追加して、”../hello-jni/Default”のように指定。


C++ アタッチデバッグの設定
  • C++ プロジェクトをクリックして、選択状態にする。
  • 「Run」メニューから「Debug Configurations...」を選択。
  • 「C/C++ Attach to Application」 を右クリックして、コンテキストメニューから「New」を選択。
  • 作成されたデバッグ設定をクリック。
  • 「Main」タブの「C/C++ Application」が”Default\ DLL ファイル名”、「Project」がC++ プロジェクト名になっていることを確認。
  • 「Close」ボタンを押す。

デバッグ開始


デバッグを開始する手順は次のようにする。
  • Javaのソースにブレイクポイントを設定。ただし、 System.loadLibrary で 作成した DLL のロード後の場所に設定すること。
  • Java のデバッグを開始。
  • C++ のデバッグを開始。アタッチするプロセス ID を設定するダイアログが開くので、上で実行したプロセス(javaw.exe)の ID を tasklist コマンドか、タスクマネージャで調べて入力する。javaw.exe プロセスは、eclipse 本体もあるので、間違って eclipse 本体のプロセスを指定しないこと。
  • C++ ソースにブレイクポイントを設定する。ここ重要、必ず C++ デバッグ開始直後の状態(GDB が起動して、一時停止の状態)でブレイクポイントを設定すること。ブレイクポイントを解除しなくても無効にして有効にすれば問題ない。ブレイクポイントのマークをよく見ると、有効な場合は、丸の上にチェックが付いている。無効な場合には、丸だけ。さらに、ソース上のブレイクポイント行に!マークが付き”Breakpoint attribute problem: installation failed”と表示される。
  • C++ デバッグを再開(Resume(F8))する。再開後に C++ のブレイクポイントの設定はできない。C++ のブレイクポイントで一時停止した状態にならないとブレイクポイントの設定はできない。
  • Java デバッグを再開すると C++ のブレイクポイントで停止する。はず。


いろいろやってると、eclipse が反応しなくなるときがある。そんなときは、GDB のプロセスが残ってる場合があるので、taskkill コマンドかタスクマネージャから gdb.exe プロセスを停止するといい。

2010年7月16日金曜日

Google ツールバーでマウスオーバー翻訳ができなくなった

気が付いたら、Google ツールバーのマウスオーバー翻訳が動作しなくなっていた。
Google ツールバー オプション画面を開く。
「ツール」タブで、「翻訳する」項目の「編集」を開く。
「翻訳する言語を選択してください:」で、なぜか”中国語簡体字)”から、”日本語”に変更して、保存しても、変更できない。

設定を、どう変更しても反映されないので、しかたなく「デフォルトに戻す」ボタンをポチッとなっ!
そしたら、正常に動作するようになったとさ。めでたしめでたし。

Eclipse CDT と MinGW(64bit版)でコンパイル

Eclipse CDT と MinGW(64bit版)でコンパイルをしてみたくなったので、やってみた。

■確認した環境

AMD Phenom(tm) II X4 955 3.20GHz
Windows Vista Business SP2 64bit

JDK 1.6.0_16  64bit
MinGW(64bit版)(mingw-w64-bin_i686-mingw_20100702_sezero.zip)
Eclipse Classic 3.6.0 64bit(eclipse-SDK-3.6-win32-x86_64.zip)
C/C++ Development Tools 7.0.0.201006141710

  • 間違いの元その1:MinGW は、元から 32bit 版が入っていて(C:\MinGW)、後から 64bit 版を入れた(C:\MinGW64)
    CDT は C:\MinGW にMinGW がインストールされていると、Path に設定されいるかは、関係なく、このディレクトリの GCC を使用してしまう。よって、32bit 版を、C:\MinGW86 にリネームした。
  • 間違いの元その2:環境変数の Path に、MinGW のパスを設定していない。
    CDT は、C:\MinGW にMingGW がインストールされていない場合は、環境変数の Path に設定された、パスから GCC を探して利用する。よって、Windows の「システムプロパティ」-「環境変数」で”Path”に”C:\MinGW64\bin”を追加した。
    GCC のパスは、Eclipse の設定で「C/C++」-「Build」-「Environment」などに設定しても、だめだった。

2010年7月10日土曜日

windows vista 64bit で JOGL 2.x をコンパイル

JOGL 2.x の 64bit 版コンパイルに、なんとか成功したようなので、手順を書いておくことにする。
以下の手順は、Java Binding for the OpenGLR API Wiki(JOGL) FAQHow To Build が元になっている。

コンパイル環境
  • Windows Vista 64bit
  • Microsoft Visual C++ 2008 Express Edition SP1
  • Java SDK 1.6.0_16 64bit
  • Ant 1.8.1
  • ANTLR 3.2
  • Git for Windows 1.0.7.2

環境の構築
OS、Visual C++ および Java は、インストール済みとする。
  1. Ant
    Ant は、このページのダウンロードサイトからダウンロードして、解凍し適当なディレクトリへインストールする。
    環境変数 path にAntをインストールした場所の bin ディレクトリを追加。
    コマンドラインで、 ant -version でバージョンが表示されればOK。
  2. ANTLR
    ANTLR は、このページのダウンロードサイトから「Complete ANTLR 3.2 jar; all tools, runtime, etc...」となっているものをダウンロードし、Ant をインストールしたディレクトリの lib ディレクトリの中へコピーする。
  3. Git for Windows
    Git for Windowsは、このページからダウンロードして、インストール

2010年7月5日月曜日

getepg.php で Segmentation fault がいっぱい

最初に気がついたのは、録画予約したはずの番組が、録画されていないことだった。
EPGREC から番組を検索しても、5日後の番組が引っかからない・・・・

はて?と思って、EPGREC の番組表を見てみると、4日後以降マッシロケ・・・
では、手動で番組表を取得してはどうかと getepg.php を実行してみたが。
Segmentation fault がいっぱい表示されてダメっぽい。
epgdump とかも疑って、再インストールしてみたが、状況は変わらず。

受信電波状況が悪いのかと、録画してみることにした。
$ recpt1 --b25 --strip 27 30 test.ts
using B25...
enable B25 strip
pid = 3075
Cannot tune to the specified channel

ぬぉ!? NHK が映らんだと!!

2010年7月2日金曜日

epgrec で録画ファイルが削除できなくなったら


epgrec で録画済ファイルを削除しようとしたときに、”Error過去の録画予約です”と表示され、削除できなくなることがある。

データベースに接続
> mysql -p
mysql> use user1

過去の録画で終了フラグが立っていないものを探す
mysql> select id, complete from Recorder_reserveTbl where endtime < now();

該当するレコードの終了フラグを立てる
mysql> start transaction;
mysql> update Recorder_reserveTbl set complete = 1 where id = 367;
mysql> commit;
mysql> \q

あとは、epgrec の録画済一覧画面から通常通り削除する。

2010年5月15日土曜日

Cubase でコードダイアグラム付きのタブ譜を作成

できないと思い込んでいた Cubase でコードダイアグラム付きのタブ譜の作成方法が、わかったので。備忘録として残しておく。

動作を確認した環境は、Cubase Studio 4

この記事の目的は、コード、コードダイアグラムおよび歌詞だけのタブ譜を作成すること。
メロディーとかその他は、知らないw

まずプロジェクトを作成する。
つぎに
「プロジェクト」メニューから「トラックを追加」-「インストゥルメント」を選択
HALionOne を選択して「OK」。
鉛筆ツールを選択(フルキーの8を押す)して必要な長さのパートを作成。
パートを選択して、「スコア」メニューから「選択したファイルを開く」を選択。

「スコア」ウィンドウを開いた状態で、「スコア」メニューから「設定」を選択。
「譜表」タブを選択し、その中の「タブ譜」タブをさらに選択。
「タブ譜モード」チェックボックスをチェック。
「適用」ボタンを押す。
「スコア設定」ウィンドウを閉じる。


「スコア」ウィンドウの「記号を表示」ツールを選択。
左側に表示された「記号」パレットから「他」を選択。

「コード記号」のボタンをクリック。

楽譜上のコード記号を追加したい場所をクリック。



「コード記号の編集」画面が開く。
「調の基音」、「ベース音」、「コードタイプ」、「テンション」を設定し、「適用」ボタンを押す。
「コード記号の編集」ウィンドウを開いたままで、楽譜をクリックして、再びコードの設定をし、「適用」ボタンを押していくと、連続してコード記号の設定が行える。
コードは、その位置を自由に移動できる。ただし、どの行に属するかに注意する必要がある。ちなみにどの行に属するかは選択してみると、行の先頭のマークと、行が青くなることで確認できる。属する行を移すには、コードをドラッグして、一度属させたい行の上を通過させるとよい。
「コード記号の編集」ウィンドウを閉じる。

次に、コードダイアグラム(Cubase 用語では 「ギターコード記号」)を追加していく。


「スコア」ウィンドウで「その他」パレットから「ギターコード記号」を選択。
楽譜上の追加したい位置をクリック。


「ギター記号」ウィンドウが開く。
ここで、一つ一つ設定もできるが、既定の設定を利用する。
「ライブラリ」をクリックすると、既定のコードが選択できる。利用したいコードがない場合、後で説明する方法でライブラリに追加することができる。
他の設定は、ご自由に(私の場合は、水平位置をチェック、5フレットに設定した)。設定を変える場合は、コードを選択してからおこなうこと。
「適用」ボタンを押す。

初期表示では、楽譜の行間隔が狭いはずだが、調整する方法がある。
「ギター記号」を置きたい位置に置く(上の行にめり込むと思う)
「スコア」メニューから「機能」-「画面表示を更新」を選択すると、自動的に間隔が調整される。

記号の縦、横位置を揃えることも出来る。
縦位置を揃えたい場合、横一列選択して、「スコア」メニューから「スコア要素の整列」-「垂直線を中心に表示」を選択する。

次に歌詞を追加していく。
今回は音符をまったく設定しないので、音符に属させる「歌詞(Lyrics)」は使えず、場所に属させる「テキスト(Text)」を使うことになる。




「スコア」ウィンドウで「その他」パレットから「Text」を選択。
楽譜上の歌詞を追加したい場所をクリック。
歌詞を入力。
このままだと、フォントが小さいので設定を変更する。
追加した歌詞を右クリックして、コンテキストメニューの「属性」を選択。




「フォント設定」で「フォント」および「サイズ」を設定。
「適用」ボタンを押す。

次に印刷を行うための設定を行っていく。
印刷はトラック単位で行いたい(パート単位では普通行いたくないはず)ので、「スコア」ウィンドウを閉じる。
「スコア」メニューから「レイアウトを開く」を選択。

「レイアウトを開く」ウィンドウで、開きたいレイアウトを選択して、「OK」ボタンを押す。
「スコア」メニューから「ページモード」を選択。
印刷イメージに近い形で表示される。
このままで満足なら、そのまま印刷すればいいが、私の場合は我慢できず・・・

「スコア」メニューから「オートレイアウト」を選択。
「オートレイアウト」ウィンドウで、「小節と譜表を調整」を選択。
「大譜表の最小間隔」を”60”に設定。
「最大小節数」を”4”に設定。
「OK」ボタンを押す。

ちなみに「全てを最適化」で有効となる「”垂直配置の調整”最下段の間隔」は、1ページに満たない場合、行を均等に配置してしまうので、使いたくない。(回避できる設定があるのだろうか?)



ページは、「スコア」ウィンドウの右下で切り替えることができる。

「ファイル」メニューから「印刷」を選択。
これで、とりあえずコードダイアグラム付きタブ譜が出力できる。


最後に、既定のコードダイアグラムに新たなコードを追加したい場合の手順について説明する。
「スコア」ウィンドウを表示した状態で、「スコア」メニューから「設定」を選択。


「スコア設定」ウィンドウで「プロジェクト」タブを選択。
「ページ」から「ギターコードライブラリ」を選択。


「新規」ボタンを押す。選択していたコードの下に、新規コードが追加される。
追加された新規コードのコードダイアグラム(左側)をダブルクリックする。(コード(右側)をダブルクリックすると別の設定画面が出るので注意)


上がヘッド側、右が1弦となる。
私の場合、左がヘッド側の表記に慣れているため、「水平位置」をチェック、5フレットに設定した。

設定方法は、マニュアルに書いてあるが、一応説明すると。
弦の上をクリックすると、押さえる箇所を指定できる。もう一度押すと消える。
ヘッド側の空白をクリックすると、開放、ミュート弦の設定が行える。
6弦の左側の空白をクリックすると、端のフレットの番号を変えることが出来る。


必要な設定をして、「終了」ボタンを押す。


設定した内容を判別し、自動的にコード名が付く。
「ソート」ボタンを押すと、コード順にソートされる。

以上説明終わり。


しかし、こういうことは周知の事実なんだろうか?
ググってもたいした情報がでてこない。まあ、マニュアル嫁ってことか・・・
ツールを使っているのか、ツールに使われているのか、分からなくなってくる・・・

2010年5月2日日曜日

リポジトリをApacheでさらす設定 - Apache 編

Subversion のリポジトリを Apache でさらすときの設定を書いておく。
概要
  • 参照用は、HTTP 接続で、無制限アクセス。
  • フルアクセス用は、HTTPS 接続必須で、制限アクセス。
  • それぞれの URL は別にして、同一のリポジトリをアクセスする。
  • 一部の URL は、ローカルネット内からのみアクセス可とする。


#
# リポジトリー(参照用)
#
<Location /svn>
  DAV svn
  SVNParentPath "/var/svn"
  AuthzSVNAccessFile /etc/apache2/svn/dav_authz

  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Order Allow,Deny
    Deny from All
  </LimitExcept>
</Location>
<Location /svn/trac_ja>
  Order Deny,Allow
  Deny from all
</Location>
<Location /svn/private>
  Order Deny,Allow
  Deny from all
</Location>


#
# リポジトリー(書き込み用)
#
<Location /svn/dev>
  DAV svn
  SVNParentPath "/var/svn"
  AuthzSVNAccessFile /etc/apache2/svn/dav_authz
  SSLRequireSSL
  AuthType Digest
  # AuthName の値と digest パスワードの realm を合わせる必要がある
  AuthName "Subversion repositories"
  AuthUserFile "/etc/apache2/svn/dav_digestpw"

  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Order Allow,Deny
    Allow from All
    Require valid-user
  </LimitExcept>
</Location>

<Location /svn/dev/trac_ja>
  Order Allow,Deny
  Allow from 192.168.1.0/255.255.255.0 127.0.0.0/255.0.0.0
  Require valid-user
</Location>

<Location /svn/dev/private>
  Order Allow,Deny
  Allow from 192.168.1.0/255.255.255.0 127.0.0.0/255.0.0.0
  Require valid-user
</Location>

期限切れ SSL用証明書の再作成 - 玄箱(Debian)編

うちの玄箱で運用している Apache の、SSL 用証明書が期限切れとなった。
ちなみに、玄箱の OS は、Debian に差し替え済み。
(SSL 用証明書の新規作成は、絶対領域 (AbsoluteArea)の徒然: そして玄箱へ… LV8 を参照)

よって、証明書の再作成をおこなう。多分正式には、証明書を破棄したりしないとならないのかも。
しかし、証明書の上書きという暴挙に出てみた。ま、所詮オレオレ証明書なので・・・
ちなみに、使用しているコマンドは、SSL 用証明書の新規作成時にカスタマイズした(といっても有効期限を延ばしただけ)コマンドなので、詳細は前述のリンクを参照されたし。

# make-ssl-cert-365days /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/apache2.pem --force-overwrite

いろいろ聞かれるが、前回入力したものがデフォルト値として表示されるので、そのまま了解し続けて、終了。

Apache を再起動
# apache2ctl restart

ブラウザでアクセスしてみると、無事、証明書が更新されていた。めでたしめでたし。

2010年4月25日日曜日

拡張現実の旅-NyARToolkit C# 編 1泊目

本家の ARToolKit のビルドには、あっさり敗北して思い知った。もはやC言語には戻れない体になってしまっていることを・・・

出来ないものは、しょうがないよねっ!
気を取り直して、よく考えてみた。
「別に全部C言語じゃなくてもよくね?」
というわけで、メイン部分は C# ですることにした。

調べてみると、ARToolKit には、NyARToolkit という C# での実装版が存在し、OpenCL には、OpenCL .NET という C# ラッパーがあるようだ。

NyARToolkit は、オリジナルを参考に実装しなおしているらしい。ソースコードレベルでは、移植ではなく別物と考えたほうがよさそうだ。API レベルでは、互換があるとのこと。

動作環境は以下とする。Windows Vista Business 64bit SP2
AMD Phenom II X4 955 3.20GHz
ATI HD4890  メモリ 1G

以下のものは導入済みとして作業を進める。
Microsoft DirectX SDK (February 2010)
Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1
Visual C# 2008
ATI Stream SDK 2.01 Vista, Win7 64bit

では、以下の必要なものをダウンロードしてくる。
FrontPage - NyARToolkit から NyARToolkitCS-2.5.1.zip
SourceForge.net: OpenCL .Net から OpenCLNet 0.4.zip


最初は、OpenCL .NET からいってみる。
OpenCLNet 0.4.zip ファイルを適当な場所に解凍する。
上記解凍場所の source\OpenCLNet.sln を Visual C# で開く

なんだか、「プロジェクトの場所は信頼されていません」とか言われる。
なんだろう?
とりあえず、全て「OK」ボタンを押しておく。

2010/04/26 追記 : [プロジェクトの場所は信頼されていません] ダイアログ ボックス ページの下の方にあるコミュニティ コンテンツを見て対処法は分かったが、上の方の説明は意味不明。専門用語を専門用語で説明すんなっ!

何も考えず、ソリューションのリビルドをしてみる。
成功。

ImageCrossFade プロジェクトをスタートアッププロジェクトに設定して、実行してみる。
動いているようだ。


次に、NyARToolkit をコンパイルしてみる。
Visual C# で ”forFW2.0\NyARToolkitCS.sln”を開く。

またもや、「プロジェクトの場所は信頼されていません」とか言われる。
なんだろう?
やっぱり、全て「OK」ボタンを 押しておく。


Web カメラを接続してから、”CaptureTest”プロジェクトをスタートアッププロジェクトに設定して、実行してみる。
ウィンドウが開き、Web カメラの映像が表示される。タスクマネージャからプロセスを確認すると、64bit モード(プロセス名の末尾に”*32”が付いていない)で動作していることを確認できた。

なんだか、あっけないくらいにうまくいった。やっぱりソースは生もの。時間が経つと腐敗していく。
はじめから NyARToolkit にしておけばよかった。


では、今回はここまで。

2010年4月18日日曜日

拡張現実の旅-ARToolKit 編 1泊目

野望成就のため、今回は、ARToolKit を改造するための開発環境を構築する。
野望とは、拡張現実を並列プログラミング技術で高速化すること!!しかも 64bit で!!
なので、ARToolKit を使って何かを作るのではなく、ARToolKit 自身をイジルノダ!

前提環境


全てを 64bit 化するため、ソースからビルドすることにした。
作業の前に 32bit と 64bit アプリの違いについて調べた。
ASCII.jp:32bitアプリを64bit Windows 7で動かす「WOW64」|あなたの知らないWindows
WOW64 - Wikipedia などによると、32bit アプリが、%SystemRoot%\System32 にアクセスしようとすると、%SystemRoot%\SysWOW64 にリダイレクトされるようだ。つまり、32bit の DLL は、SysWOW64 の下に、64bit の DLL は、System32 の下に配置すればいいことになる。これを踏まえて以下の作業を行う。


必要なものをダウンロードする。
ARToolKit Home Page から ARToolKit2.65.zip をダウンロード
Nate Robins - OpenGL - GLUT for Win32 から glut-3.7.6-src.zip をダウンロード


では、はじめに GLUT をコンパイルしていく。
glut-3.7.6-src.zip を解凍する。
Visual C++ で glut.dsw を開く


「すべてはい」ボタンを押す。


「ビルド」メニューから「構成マネージャ」を選択

構成マネージャダイアログが開く。



「アクティブ ソリューション プラットフォーム」ドロップダウンから、「<新規作成...>」を選択。


「新しいプラットフォーム」ドロップダウンで、”x64”を選択し、「OK」ボタンを押す。


「プラットフォーム」が”x64”になっていることを確認したら、「閉じる」ボタンを押す。


次に、ビルド後に自動的に DLL ファイルなどをコピーする設定を変更する。
正しくコピー先を設定してもいいが、コピー時に権限がなくて失敗する。Visual C++ を管理者権限で動かせばいいのかもしれないが、個人的に許容できない。
したがって、ファイルコピーは手動ですることにした。ついでに、ビルド中に生成されるファイルの出力先が、いろいろ気に入らないので、修正する。

「glut32」プロジェクトのプロパティを開く。


「構成プロパティ」-「ビルド イベント」-「ビルド後のイベント」を選択。


「構成」ドロップダウンで”Debug”を選択。
「プラットフォーム」ドロップダウンで”すべてのプラットフォーム”を選択。
「コマンド ライン」のcopy $(TargetDir)glut32.dll %WINDIR%\SYSTEM32
copy $(TargetDir)glut32.lib "$(DevEnvDir)..\..\VC98\lib"
copy ..\..\include\GL\glut.h "$(DevEnvDir)..\..\VC98\include\GL"
の全て、および「説明」の設定を消す。

「構成」ドロップダウンで”Release”を選択。
「プラットフォーム」ドロップダウンで”すべてのプラットフォーム”を選択。
「コ マンド ライン」のcopy $(TargetDir)glut32.dll %WINDIR%\SYSTEM32
copy $(TargetDir)glut32.lib "$(DevEnvDir)..\..\VC98\lib"
copy ..\..\include\GL\glut.h "$(DevEnvDir)..\..\VC98\include\GL"
の全て、およ び「説明」の設定を消す。
「適用」ボタンを押す。


「構成プロパティ」-「全般」を選択する。
「構成」ドロップダウンから”すべての構成”を 選択。
「プラットフォーム」ドロップダウンから”すべてのプラットフォーム”を選択。
「出力ディレクトリ」 に”$(SolutionDir).build\$(PlatformName)\$(ConfigurationName)”を設定。
「中間ディレクト リ」に”.build\$(PlatformName)\$(ConfigurationName)”を設定。
「OK」ボタンを押す。



「構成プロパティ」-「C/C++」-「プリコンパイル済みヘッダー」を選択する。
「構成」ドロップダウンから”すべての構成”を 選択。
「プラットフォーム」ドロップダウンから”すべてのプラットフォーム”を選択。
「プリコンパイル済みヘッダー ファイル」 に”$(IntDir)\glut32.pch”を設定。
「OK」ボタンを押す。

「構成プロパティ」-「C/C++」-「出力ファイル」を選択する。

「構成」ドロップダウンから”Debug”を 選択。
「プラットフォーム」ドロップダウンから”すべてのプラットフォーム”を選択。
「ASM リストの場所」の設定を削除。
「構成」ドロップダウンから”Release”を 選択。
「プラットフォーム」ドロップダウンから”すべてのプラットフォーム”を選択。
「ASM リストの場所」の設定を削除。

「構成」ドロップダウンから”すべての構成”を 選択。
「プラットフォーム」ドロップダウンから”すべてのプラットフォーム”を選択。
「オブジェクト ファイル名」に”$(IntDir)\”を設定。 「プログラム データベース ファイルの名前」に”$(IntDir)\vc90.pdb”を設定。
「適用」ボタンを押す。


「構成プロパティ」-「リンカ」-「全般」を選択。
「構成」ドロップダウンで”すべての構成”を選択。
「プラットフォーム」ドロップダウンで”すべてのプラットフォーム”を選択。
「出力ファイル」に”$(OutDir)\glut32.dll”を設定。
「適用」ボタンを押す。



「構成プロパティ」-「リンカ」-「デバッグ」を選択。
「構成」ドロップダウンで”すべての構成”を選択。
「プラット フォーム」ドロップダウンで”すべてのプラットフォーム”を選択。
「プログラム データベース ファイルの生成」に”$(TargetDir)$(TargetName).pdb”を設定。
「適用」ボタンを押す。




「構成プロパティ」-「リンカ」-「詳細」を選択。
「構成」ドロップダウンで”すべての構成”を選択。
「プラット フォーム」ドロップダウンで”すべてのプラットフォーム”を選択。
「インポート ライブラリ」に”$(TargetDir)\glut32.lib”を設定。
「適用」ボタンを押す。




「構成プロパティ」-「ブラウザ情報」-「全般」を選択。
「構成」ドロップダウンで”すべての構成”を選択。
「プラット フォーム」ドロップダウンで”すべてのプラットフォーム”を選択。
「出力ファイル」に”$(OutDir)\glut32.bsc”を設定。
「適用」ボタンを押す。






では、ビルドしてみる。
一つずつ手動でやってもいいのだが、面倒なのでバッチビルドを行うとこにする。
「ビルド」メニューから「バッチビルド」を選択


「ビルド」チェックボックスを全てチェックする。
「ビルド」ボタンを押す。


中間生成ファイルは、プロジェクトディレクトリ中の .build\プラットフォーム名\構成名 ディレクトリ以下に出力される。(例 : glut-3.7.6\lib\glut\.build\x64\Debug)


最終出力ファイルは、ソリューションディレクトリ中の .build\プラットフォーム名\構成名 ディレクトリ以下に出力される。(例 :glut-3.7.6\.build\x64\Debug)


想定通りにファイルが、出力されていることを確認する。想定通りでない場合は、設定を見直す。


最後に、生成されたファイルを手動で配置していく。

DLL ファイルの配置
glut-3.7.6\.build\Win32\Release\glut32.dll を %SystemRoot%\SysWOW64 ディレクトリにコピー
glut-3.7.6\.build\x64\Release\glut32.dll を %SystemRoot%\System32 ディレクトリにコピー

%SystemRoot% は、コマンドラインで echo %SystemRoot% とすると、実際のパスを知ることが出来る。(私の環境では、”C:\Windows”だった)


LIB ファイルと ヘッダファイルの格納先を確認する。
「glut32」プロジェクトのプロパティを開く。
「構成プロパティ」-「全般」を選択。


「出力ディレクトリ」のドロップダウンから”<編集...>”を選択。


 「マクロ」ボタンを押す。
”VCInstallDir”の値を確認する。(私の環境では、”C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\”だった)
以下 Visual C++ インストールディレクトリを %VCInstallDir% と記載する。


LIB ファイルの配置
glut-3.7.6\.build\Win32\Release\glut32.lib を %VCInstallDir%\lib ディレクトリにコピー
glut-3.7.6\.build\x64\Release\glut32.lib を %VCInstallDir%\lib\amd64 ディレクトリにコピー



ヘッダファイルの配置
glut-3.7.6\include\GL\glut.h を %VCInstallDir%\include\GL ディレクトリを作成してその中にコピー


今回はここまで。次回は、いよいよ ARToolKit 本体をコンパイルする環境を構築していくことにする。


追記:
本体をコンパイルするつもりだったが、あまりにも手順が面倒なので、挫折・・・
その内リベンジする予定・・・・予定は未定・・・・


VC++ 2008 Express EditionでARToolkitをビルドしてみる - やざわラボ Wiki: とかが参考になると思う。

2010年4月5日月曜日

OpenCLマスターへの道 - ATI Stream SDK 編 第六話

今回は、サンプルソースを 64bit 版のWin32 コンソールアプリケーションとしてビルドしてみる。

参考にしたドキュメントは、”ATI Stream SDK OpenCL™ Programming Guide (v1.0) [PDF 900 KB]”
このファイルには、以下の手順で たどりつける。

「スタート」メニューから「すべてのプログラム」-「ATI Stream SDK v2」-「ATI Stream SDK Documentation」を選択すると、ブラウザで、「ATI Stream SDK v2.01 Documentation」のページが開く。開いたページのリスト中に上記ファイルがある。

Visual C++ 2008 Express Edition を起動する。

「ファイル」メニューから「新規作成」-「プロジェクト」を選択。


「プロジェクトの種類」から「Win32」を選択する。
「テンプレート」から「Win32 コンソール アプリケーション」を選択する。
「プロジェクト名」に”HelloCL”と入力し、「OK」ボタンを押す。


次に”HelloCL.cpp”ファイルを編集していく。


楽をするために、ATI Stream SDK のサンプルファイルの中身をコピーする作戦でいくことにする。
コピー元は、サンプルをインストールしたディレクトリ以 下”samples\opencl\cpp_cl\app\HelloCL\”の”HelloCL.cpp”と”HelloCL_Kernels.cl” とする。



”HelloCL_Kernels.cl” はそのまま、”HelloCL”プロジェクトのディレクトリにコピーして、既存の項目として「ソースファイル」に追加。

サ ンプルの”HelloCL.cpp”ファイルからインクルード行とmain関数の中身をコピーする。
main 関数の定義部分は、書き換えないことにする。

// HelloCLWin32.cpp : コンソール アプリケーションのエントリ ポイントを定義します。
//

#include <cstdio>
#include <cstdlib>
#include <iostream>
#include <sdkutil/sdkfile.hpp>
#include <sdkutil/sdkcommon.hpp>

#define __NO_STD_VECTOR
#define __NO_STD_STRING

#include <cl cl.hpp>
#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{
    cl_int err;

    // Platform info
    cl::vector<cl::platform> platforms;
    std::cout<<"HelloCL!\nGetting Platform Information\n";
    err = cl::Platform::get(&platforms);
    if(err != CL_SUCCESS)
    {

<中 略>

    err = queue.finish();
    if (err != CL_SUCCESS) {
        std::cerr << "Event::wait() failed (" << err << ")\n";
    }

    delete pProgram;

    std::cout<<"Done\nPassed!\n";
    return SDK_SUCCESS;
}


上記ソース中で”SDKUtil”を利用している ので、ドキュメントの手順をみると、インクルードファイルとライブラリ指定を追加するだけで大丈夫となっているが、”SDKUtil.lib”なんてどこ にもない。 しかたがないので、ドキュメントの手順は実行しない。


実行しない手順の代わりに、”SDKUtil”をサンプルからプロジェクトごと、新規作成し た”HelloCL”ソリューションの下にコピー。
既存のプロジェクトとして追加。
このままだと、とんでもね~ところにビル ド済みファイルを吐き出すので、以下のように設定を変更。


”SDKUtil”プロジェクトのプロパティを開く。
 「構成プロパティ」-「全般」を選 択。
「出力ディレクトリ」とし て”$(SolutionDir)$(PlatformName)\$(ConfigurationName)”を設定。
「中間ディレクト リ」として”$(PlatformName)\$(ConfigurationName)”を設定。



プロジェクトの依存関係を以下のように設定。
ソリューションのプロパティを開く。
「共 通プロパティ」-「プロジェクト依存関係」を選択。
「プロジェクト」には”HelloCL”を選択。
「依存先」 で”SDKUtil”をチェックして、「OK」ボタンを押す。


次に、OpenCL 本体のヘッダやライブラリに関する追加設定を、ドキュメントの手順で設定する。


”HelloCL”プロジェクトのプロパティを開く。
「構成プロパティ」-「C/C++」 -「全般」を選択。
「追加のインクルード ディレクトリ」に”"$(ATISTREAMSDKSAMPLESROOT)\include";"$(ATISTREAMSDKROOT)\include"” を設定。


「構成プロパティ」-「C/C++」-「プリプロセッサ」を選択。
「プリプロセッサの定 義」に”ATI_OS_WIN”を追加。


「構成プロパティ」-「リンカ」-「全般」を選択。
「追加のライブラリ ディレクトリ」に”$(ATISTREAMSDKROOT)/lib/x86”を追加。


「構成プロパティ」-「リンカ」-「入力」を選択。
「追加の依存ファイル」 に”OpenCL.lib”を追加。
「OK」ボタンを押す。


では、32bit版をビルドしてみる。「ビルド」メニューから「ソリューションのビルド」を選択。


error C2065: 'cl_int' : 定義されていない識別子です。
error C2146: 構文エラー : ';' が、識別子 'err' の前に必要です。
error C2065: 'err' : 定義されていない識別子です。
error C2653: 'cl' : 識別子がクラス名でも名前空間名でもありません。
error C2065: 'vector' : 定義されていない識別子です。
error C2653: 'cl' : 識別子がクラス名でも名前空間名でもありません。
error C2065: 'Platform' : 定義されていない識別子です。
error C2065: 'platforms' : 定義されていない識別子です。
error C2653: 'std' : 識別子がクラス名でも名前空間名でもありません。
error C2065: 'cout' : 定義されていない識別子です。
error C2065: 'err' : 定義されていない識別子です。

<中略>

error C2065: 'cerr' : 定義されていない識別子です。
error C2065: 'err' : 定義されていない識別子です。
error C2065: 'SDK_FAILURE' : 定義されていない識別子です。
error C2065: 'devices' : 定義されていない識別子です。
error C2228: '.size' の左側はクラス、構造体、共用体でなければなりません
        型は ''unknown-type'' です。
error C2653: 'std' : 識別子がクラス名でも名前空間名でもありません。
error C2065: 'cerr' : 定義されていない識別子です。
error C2065: 'SDK_FAILURE' : 定義されていない識別子です。
error C2653: 'std' : 識別子がクラス名でも名前空間名でもありません。
error C2065: 'cout' : 定義されていない識別子です。
fatal error C1003: プログラム内のエラーが 100 個を超えました。コンパイルは中断されます。
ビルドログは "file://e:\work\program\VisualStudio2008\CPProjects\HelloCL\HelloCL\Debug\BuildLog.htm" に保存されました。
HelloCL - エラー 102、警告 8
========== ビルド: 1 正常終了、1 失敗、0 更新不要、0 スキップ ==========


大量にエラーになった。何かが間違っているようだ。
どうやら、#include "stdafx.h" の記述位置が悪いらしい、最初に持ってきてみる。 (そもそもプリコンパイルヘッダについて無知なのでトンチンカンなことをやっているかもしれない)

再びビルド。今度は先ほどとは違うエラーでいっぱいだ・・・



msvcprtd.lib(MSVCP90D.dll) : error LNK2005: "public: unsigned int __thiscall std::basic_string>char,struct std::char_traits>char<,class std::allocator>char< <::size(void)const " (?size@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEIXZ) は既に sdkutil.lib(SDKFile.obj) で定義されています。
msvcprtd.lib(MSVCP90D.dll) : error LNK2005: "public: __thiscall std::basic_string>char,struct std::char_traits>char<,class std::allocator>char< <::basic_string>char,struct std::char_traits>char<,class std::allocator>char< <(char const *)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@PBD@Z) は既に sdkutil.lib(SDKFile.obj) で定義されています。
msvcprtd.lib(MSVCP90D.dll) : error LNK2005: "public: void __thiscall std::basic_ios>char,struct std::char_traits>char< <::setstate(int,bool)" (?setstate@?$basic_ios@DU?$char_traits@D@std@@@std@@QAEXH_N@Z) は既に sdkutil.lib(SDKFile.obj) で定義されています。
msvcprtd.lib(MSVCP90D.dll) : error LNK2005: "public: static bool __cdecl std::char_traits>char<::eq_int_type(int const &,int const &)" (?eq_int_type@?$char_traits@D@std@@SA_NABH0@Z) は既に sdkutil.lib(SDKFile.obj) で定義されています。



とか


libcpmtd.lib(ios.obj) : error LNK2005: "private: static void __cdecl std::ios_base::_Ios_base_dtor(class std::ios_base *)" (?_Ios_base_dtor@ios_base@std@@CAXPAV12@@Z) は既に msvcprtd.lib(MSVCP90D.dll) で定義されています。
libcpmtd.lib(ios.obj) : error LNK2005: "public: static void __cdecl std::ios_base::_Addstd(class std::ios_base *)" (?_Addstd@ios_base@std@@SAXPAV12@@Z) は既に msvcprtd.lib(MSVCP90D.dll) で定義されています。
libcpmtd.lib(locale0.obj) : error LNK2005: "void __cdecl _AtModuleExit(void (__cdecl*)(void))" (?_AtModuleExit@@YAXP6AXXZ@Z) は既に msvcprtd.lib(locale0_implib.obj) で定義されています。
libcpmtd.lib(locale0.obj) : error LNK2005: __Fac_tidy は既に msvcprtd.lib(locale0_implib.obj) で定義されています。


とか


libcpmtd.lib(xlock.obj) : error LNK2005: "public: __thiscall std::_Lockit::_Lockit(int)" (??0_Lockit@std@@QAE@H@Z) は既に msvcprtd.lib(MSVCP90D.dll) で定義されています。
libcpmtd.lib(xlock.obj) : error LNK2005: "public: __thiscall std::_Lockit::~_Lockit(void)" (??1_Lockit@std@@QAE@XZ) は既に msvcprtd.lib(MSVCP90D.dll) で定義されています。
LIBCMTD.lib(setlocal.obj) : error LNK2005: __configthreadlocale は既に MSVCRTD.lib(MSVCR90D.dll) で定義されています。
LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtSetCheckCount は既に MSVCRTD.lib(MSVCR90D.dll) で定義されています。
LIBCMTD.lib(tidtable.obj) : error LNK2005: __encode_pointer は既に MSVCRTD.lib(MSVCR90D.dll) で定義されています。
LIBCMTD.lib(tidtable.obj) : error LNK2005: __decode_pointer は既に MSVCRTD.lib(MSVCR90D.dll) で定義されています。
LIBCMTD.lib(winxfltr.obj) : error LNK2005: __XcptFilter は既に MSVCRTD.lib(MSVCR90D.dll) で定義されています。



とか


LINK : warning LNK4098: defaultlib 'MSVCRTD' は他のライブラリの使用と競合しています。/NODEFAULTLIB:library を使用してください。
LINK : warning LNK4098: defaultlib 'LIBCMTD' は他のライブラリの使用と競合しています。/NODEFAULTLIB:library を使用してください。
LIBCMTD.lib(crt0.obj) : error LNK2019: 未解決の外部シンボル _main が関数 ___tmainCRTStartup で参照されました。

HelloCL - エラー 51、警告 2
========== すべてリビルド: 1 正常終了、1 失敗、0 スキップ ==========




まだ設定が足りないらしい、色々調べると以下の手順が足りてないようだ。
この手順は、ドキュメントには書いていない、でもサンプルプロジェクトでは、設定されている。

”HelloCL”プ ロジェクトのプロパティを開く。




「構成のプロパティ」-「C/C++」-「コード生成」を選択。
「ラ ンタイム ライブラリ」を”マルチスレッド デバッグ DLL (/MDd)” から ”マルチスレッド デバッグ (/MTd)”に変更して、「OK」ボタンを押す。(ここらへんについても無知なのでよくわからない)

再びビルドする。


今度はうまくいった。
では、実行してみる。

「デバッグ」メニューから「デバッグなしで開始」を選択



HelloCL!
Getting Platform Information
Platform::get() failed (-1001)
続行するには何かキーを押してください . . .




ありゃ?なんでじゃ?

サンプルプログラムを動かしても、同様の状態・・・なんかオレに恨みでもあんのか?
64bit 対応化騒動で、何か大切なものを無くしてしまったのか?

ATI Stream SDK をインストーラでリペアしてもだめだった。
しかたがないので、ATI Stream SDK をアンインストール後、再びインストールした。サンプルをコンパイルして動作確認。うまくいった。
ようやく、”HelloCL”に戻ってきた。
こっちもビルドして実行。成功!

では、本題の 64bit 版をビルドする。

その前に、”HelloCL”プロジェクトのプロパティを開く。


「構成プロパティ」-「リンカ」-「全般」を選択する。
「追加のライブラリ ディレクトリを”$(ATISTREAMSDKROOT)/lib/x86_64”に変更する。
「OK」ボタンを押す。


「ビルド」メニューの「構成マネージャ」を選択。


”HelloCL”プロジェクトの「プラットフォーム」から”<新規作成>”を選択する。


「新しいプラットフォーム」で”x64”を選択し、「OK」ボタンを押す。
もし”同じ名前のソリューション プラットフォームが既に存在するため、このプラットフォームを作成できませんでした。”と表示される場合は、「キャンセル」ボタンを押して、「構成マネージャ」の「アクティブ ソリューション プラットフォーム」で”<編集>”を選択し、”x64”を削除してから、再びこの手順を行う。

こんな画面になる。
「閉じる」ボタンを押す。

「ビルド」メニューから「ソリューションのビルド」を選択する。
ビルドが成功したら。

「デバッグ」メニューから「デバッグなしで開始」を選択。


HelloCL!
Getting Platform Information
Creating a context AMD platform
Getting device info
Loading and compiling CL source
Running CL program
Done
Passed!
続行するには何かキーを押してください . . .


よし!成功!

長かった・・・丸二日もかかってしまった。

能力不足を再認識・・・欝だ・・・もう寝よう。

というわけで、今回はここまで。

2010年4月4日日曜日

OpenCLマスターへの道 - ATI Stream SDK 編 第五話

前回、サンプルプログラムが動いたので、今回は、プロジェクトを始めから作成してみる。


ただし、普通にやってもつまらないので、64bit CLR コンソールアプリケーションを作成してみる。


とその前に、Express Edition は、64bit 版のビルドはサポート外なので、Microsoft Visual C++ 2008 Express Edition で64ビット版のプログラムを作る方法を参考に(ありがたやありがたや~)以下のものを導入して、64bit 版をビルドできるようにした。

Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1
Visual C++ 2008 Express Edition And 64-Bit Targets本文中の”Updated patch for Win7 SDK:”の下の”VCE64BIT_WIN7SDK.zip”


最初、私の環境では、以下の手順を実施してもうまくいかなかった。
おそらく、Visual C++ をデフォルトのディレクトリにインストールしていなかったのが原因と思われる。
しかたがないので、Visual シリーズ(C#など)、および、Windows SDK など関係するものを全てアンインストールして、Visual Studio に関連する設定ファイルをすべて削除し、アンインストールしたものをインストールし直す、その際にインストール先をデフォルト値のままとし、再び以下の手順を繰り返したらうまくいった。



64bit 版ビルド対応化の手順は以下のようにする。
Visual C++ 2008 Express Edition with SP1 をインストール。
インストール後、Windows Update を実行し、Visual C++ を最新の状態にしておくこと。

Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1のページから”winsdk_web.exe”をダウンロードして実行する。画面の指示通りにインストールする。

”VCE64BIT_WIN7SDK.zip”を解凍する。
解凍したファイルの”readme.txt”を開いて読む。
”readme.txt”の手順3は、リンク先の情報をよく読むこと、OSが32bitか64bitかで手順が変わるようだ。私のマシンはVista 64bitなので手順1は行わなかった(確証なし)
手順2として、「スタート」メニューから「すべてのプログラム」-「Microsoft Windows SDK v7.0」-「Visual Studio Registration」-「Windows SDK Configuration Tool」を実行


「Installed Windows SDK Versions:」で”v7.0”を選択。
「Make Current」ボタンを押す。


成功。「OK」ボタンを押す。

次に、コマンドプロンプトを管理者権限で開く。手順は次のようにする。
「スタート」メニューから「すべてのプログラム」-「アクセサリ」-「コマンドプロンプト」を右クリックして、コンテキストメニューから「管理者として実行」を選択。

開いたコマンドプロンプトで”VCE64BIT_WIN7SDK.zip”を解凍したディレクトリに移動する。

”setup_x64.bat”を実行する。(32bit OSの場合は”setup_x86.bat”)


> setup_x64.bat

> regedit /s x64\VC_OBJECTS_PLATFORM_INFO.reg

> regedit /s x64\600dd186-2429-11d7-8bf6-00b0d03daa06.reg

> regedit /s x64\600dd187-2429-11d7-8bf6-00b0d03daa06.reg

> regedit /s x64\600dd188-2429-11d7-8bf6-00b0d03daa06.reg

> regedit /s x64\600dd189-2429-11d7-8bf6-00b0d03daa06.reg

> regedit /s x64\656d875f-2429-11d7-8bf6-00b0d03daa06.reg

> regedit /s x64\656d8760-2429-11d7-8bf6-00b0d03daa06.reg

> regedit /s x64\656d8763-2429-11d7-8bf6-00b0d03daa06.reg

> regedit /s x64\656d8766-2429-11d7-8bf6-00b0d03daa06.reg

> copy "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcpackages\AMD64.VCPlatform.config" "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcpackages\AMD64.VCPlatform.Express.config"
        1 個のファイルをコピーしました。

> copy "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcpackages\Itanium.VCPlatform.config" "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcpackages\Itanium.VCPlatform.Express.config"
        1 個のファイルをコピーしました。


Visual C++ 2008 Express Edition を起動。


「ファイル」メニューから「新規作成」-「プロジェクト」を選択。

「プロジェクトの種類」から”CLR”を選択。

「テンプレート」から”CLR コンソール アプリケーション”を選択。




「プロジェクト名」に”HelloCL”と入力し、「OK」ボタンを押す。


「ビルド」メニューの「構成マネージャ」を選択。


「プラットフォーム」で「<新規作成...>」を選択


「新しいプラットフォーム」で”Itanium”と”x64”がリストアップされていれば 64 bit ビルド対応パッチが成功している。”x64”を選択して、「OK」ボタンを押す。


変更後の画面。「閉じる」ボタンを押す。

「ビルド」メニューから「ソリューションのビルド」を選択。


こんな感じのディレクトリ構成になっていれば成功。環境によっては、多少異なるかもしれない。


というわけで、今回はここまで。