つーさのくーかん

家のNASのOpenSSLとOpenSSHのバージョンを上げた。
2017.04.20 - 1.0.2k に更新

$ tar xf openssl-1.0.2k.tar.gz
$ cd openssl-1.0.2k
$ ./config --prefix=/opt/local/openssl/1.0.2k --openssldir=/etc/ssl zlib -fPIC enable-tlsext shared
$ make -j
$ make install
$ cd /opt/local/openssl/
$ rm *
$ ln -s 1.0.2k/* .

$ tar xf openssh-7.3p1.tar.gz
$ cd openssh-7.3p1
$ ./configure --prefix=/opt/local/openssh/7.3p1 \\
  --with-tcp-wrappers --with-md5-passwords \\
  --sysconfdir=/etc/config/ssh \\
  --with-zlib=/opt/local/zlib --with-ssl-dir=/opt/local/openssl \\
  --without-stackprotect
$ make -j
$ make install
$ cd /opt/local/openssh/
$ rm *
$ ln -s 7.3p1/* .

最初 OpenSSHのconfigureで、 configure: error: OpenSSL version header not found. とか言われて、
config.log を見ると、 ./conftest がSegmentation fault ってた。
「……？」と思いながらも、 --without-openssl で試すと、今度は sizeof(short int) を調べようとしてセグフォ。
そんな馬鹿なと思って、自前で conftest 作ってオプションを色々試してたところ、
gcc に -fstack-protector-all と -fPIEをセットで渡すと int main() { return 0; } ですらセグフォで死ぬことがわかって、
--without-stackprotectをつけたら行けた。

gcc のバージョンもあげたら直るのかな……。
その前にNASを脱却して適当なPCにして適当なLinuxディストリ入れた方がいいよなーと思うのであった。

Cygwin入れてるのにわざわざmingwを別で入れるのはなあ。
Cygwin上でMinGWのgcc使えるはずだし、それでビルドできるんじゃないの。

tu-sa@t8 ~/fdk-aac-0.1.4
$ ./configure --build=i686-w64-mingw32 --host=i686-w64-mingw32 --prefix=/usr/local/fdkaac-mingw

tu-sa@t8 ~/fdk-aac-0.1.4
$ make -j

  GEN    libfdk-aac.la

で止まる。

CPU使用率も下がるし、ディスクアクセスもないし、何かを待ってる？
Makefileやら./libtool やら眺めると以下の行がマズいっぽい。

 func_convert_core_msys_to_w32_result=`( cmd //c echo "$1" ) 2>/dev/null |

cmd //c が上手く動かず、cmdが普通に起動して入力待ちになってしまうので、 cmd /c に直す。

tu-sa@t8 ~/fdk-aac-0.1.4
$ sed -i libtool -e 'sZcmd //cZcmd /cZg'

tu-sa@t8 ~/fdk-aac-0.1.4
$ make
  GEN    libfdk-aac.la
copying selected object files to avoid basename conflicts...

make できた。

どうもmsysでは、/c は c:\\ に置換されるのがデフォで、//cでそれをエスケープして単に「/c」の意味になる*1。
cmd /c に書き換えたものは、mingw+msysの環境では、同じように止まってしまって動かないんだろな。。

LPFがほしくて。

工学部だけど、アナログな信号処理とかぜんぜん勉強したことなくて、
解析学とかもまったく苦手だった情報系出身なので、
なんかLPFのサンプルプログラムとか見ても、パラメータをどう求めればいいかよくわかんなくて、
つまりどうすれば目的の関数が得られるだってばよ？ 状態だったんだけど、

色々情報を探してさまよううちに↓のページを見つけて
http://www.g200kg.com/jp/docs/makingvst/04.html

RBJ Audio-EQ-Cookbook っていう つよい文書があって、つまりこれでLPFが作れるってことらしい。
理解度はやはりイマイチだけど、とりあえず低音が取り出せるようになった。
リンク先を見るに、HPFとかBPF、EQとかも作れるっぽい。便利。
今回は目的が別のところにあるので、勉強はここまでにして先に進めよう。

以下、とりあえず試したくて即席で書いたソース。

続きを読む

このサイト「つーさのくーかん」は、TS-219P+というQNAPというメーカのNASでホストしているのだが、
CPUがARM@1.6 GHz と非力なため、何かを更新するたびにソースをとってきてからのmakeがつらい。
そうだ、distccによる クロスコンパイル環境を復活させて、ソースのコンパイルをデスクトップPCでやろう。

• arm-none-linux-gnueabi へのクロスコンパイラをCygwin64の上に用意する。
• distcc 3.1 を cygwin 64bit で make できない。
• 動かす
• apache 2.4.23 のビルドにかかる時間をはかってみた。
  • NAS単体: CC=gcc time make -j
  • NAS+デスクトップCYGIWN: CC='distcc arm-none-linux-gnueabi-gcc' time make -j 20
  • さらにcchace: CC='ccache distcc arm-none-linux-gnueabi-gcc' time make -j 20
  • cchaceの代わりにpumpモード: CC='distcc arm-none-linux-gnueabi-gcc' time pump make -j 20
• おわりに
• おわりのむこう (7月13日追記)

arm-none-linux-gnueabi へのクロスコンパイラをCygwin64の上に用意する。

u-n, yokuwakaran!

続きを読む

XGTGCTL2　開発やめた の続きになる。

あれから10年近く経っても、自分のDTM環境が、MU2000 EXから脱却できていないので、
ドラムやEQを自由にいじりやすくするために結局作っていた。
前のバージョンはHSPで作ってて、ソースコードがスパゲティ状態で、拡張なんてとても無理だったのでC#で書き直している。
gitの使い方の勉強もかねて、GitHub上で公開してみる。

リリース: https://github.com/ttsuki/XGMidiControllerForMU2000EX/releases

これを使って作った曲: Another Wing -Deep White- と、そのソースコード
スクリーンショット:

MIDIファイルからの読み込み機能はあんまり使わないので省いて、
音源とSysExでSEND/DUMPするほか、サクラMMLスクリプトではき出すようにしたりした。

もはやXGという規格がレトロ化してきている昨今。
MOXFを買おうかとか、でもソフトで何でもできる時代だしーと思うと躊躇してしまう今日この頃。

RAMDISKドライバを作る

ほんとは、これがやりたくてオレオレ認証局とか作ってたんだけど、
調べたところによると、Windowsで使えるドライバ用のコード証明書のCAは決まってて、
そればかりか、Windows 10のカーネルモードのドライバのコード署名はEV証明書でないといけないみたいで、
結局、この記事でやってるようにドライバ署名の検証をスルーしないと動かせなかった。
趣味レベルでカーネルモードドライバをちゃんと作ってリリースする道はもはや絶望的だなー……。

この記事では、

Visual Studioでのドライバの開発に必要なものをインストールして、
サンプルドライバをビルド・インストールしてみてから、
RAMDISKの容量が1GBになるよう、ソースコードを改造してみます。

制限

この記事の範疇ではFAT16なので、2GB(一説では4GB？)よりも大きいドライブは作れないはず。
FAT32への対応はすぐできるんだと思うけど、あんまり調べてない。

上記の通りドライバにコード署名できないので、ドライブを使うには、
毎回ドライバ署名の検証をスルーできる状態でWindowsを起動する必要がある。

続きを読む