昔の最近の出来事(2013.04)

2013/04/30

早くも無く遅くも無く。

Web巡回して終了。

昼頃起床。

そういや、configureスクリプトで指定する--hostとかについて。 MinGW64では、x86_64-w64-mingw32とか指定していますが、 Cygwin64ではx86_64-pc-cygwinとか x86_64-unknown-cygwinとか になるようです。x86_64とwin64は同義語として扱って良いのかしら？ もし同義語として扱うとマズい(CPUはx86_64だけどOSは32bit Windows という組み合わせがありうる) のであれば、x86_64-pc-cygwin64とかにするべきなのかも知れません。

それにしても、MinGWの x86_64-w64-mingw32は訳が判らない感じ になっているのは否定できないところかも。 以前、gdcをビルドしたときに 「version(x86_64)ではなくversion(Win64)なのは何故？」と 思った時があったのですが、この辺も若干混乱気味に思います。

x86_64と 32bit/64bitモードの関係について。どうやら、OSが(boot時に？)CPUの モードを Longモードにすると64bitアドレッシングが可能となるようですが、 32bitOS だとLongモードに移行しない(というかLongモードという 概念がそもそも無いので移行できない)ので、64bitアドレッシング にはならないという仕掛けのようです。ただし、これはアドレッシングの話。 AVX命令セットの使用可否と連動しているのかはイマイチよくわからず。 非Longモード(==Legacyモード)でもAVX命令が使用できるのならば、 「CPUはx86_64だけどOSは32bit Windows」は識別できる必要が あると思われます。まぁ、仮にLongモードとAVX命令の使用可否が連動していない としても、事実上存在しない組み合わせって事にして問題無いとは思いますが(^^;

そういやWings3D。現在でもGitHubの方 では割と頻繁にアップデートされているようなのですが、パッケージバイナリとしての リリースは2年ほど行われていません。ソースコードのアップデートが続けられているのであれば、 年1回でも適当に区切りを入れて安定版としてリリースしてもらえれば、 ソースコードに興味の無い人にとってはありがたいのでは？ と思ったりもします。

newlibは大分前から年1回 リリースになっていますが、知らない間に2.0.0になってました(^^;

覚書き。org-modeの 7.x.x ではorgのtableで日本語文字を入れた時に表が崩れるという不具合があり、 こちらのサイト で知ったパッチをあてて使っていました。 先日org-modeを8.0.2にアップデートしましたが、7.x.xと同じ不具合を抱えている ようなので引き続きパッチが必要です。

昼過ぎ起床。

そういえば最近、「前髪に肌色を混ぜる(というか前髪の透明度を上げて透かす)」 というイラストの塗り方が流行っているらしいのですが、いまひとつどういう効果が あるのか判らなかったり。 Webで検索してみたところ、光学的な効果を狙っている節もあるようですが、 「流行っている事が理由」で取り込まれている例も少なくないようで、 真意のほどは判りませんでした。

手動でごちゃごちゃやっていた emacs-w32のパッチをまとめてみたり。 configure.acをいじらなくてはならなかったのですが、慣れてないので すったもんだしてやっとまとまってみたり。configure.acをいじるにあたって こちらの ページを参考にさせていただきました。 そんな訳で置いてみます(emacs-w32_130429.patch.xz)。

ビルド方法。

1. 予めCygwinパッケージのemacs-w32をインストールしておきます。
2. 次の手順でソースからビルドします。ビルドに必要なパッケージが揃ってなければ揃えてください。 emacs-24.3のtar-ballは適当な所から拾ってください。

   xz -dc emacs-24.3.tar.xz | tar xf -
   xz -dc emacs-w32_130429.patch.xz | patch -p0
   cd emacs-24.3
   ./configure --prefix=/usr --with-w32 --with-rsvg --without-imagemagick
   make
       

3. /usr/bin/emacs-w32.exe をビルドしたsrc/emacs.exe で置き換える。 元の実行ファイルは別名で退避しておくのが良いでしょう。
4. lisp/international/w32-ime.el と lisp/international/w32-ime.elc を /usr/share/emacs/24.3/lisp/international/. にコピーする。
5. 以下の設定を.emacs(オールドスタイルですみません)に追加する。

   ;;
   ;; IME setup
   ;;
   (set-language-environment	"Japanese")
   (if (featurep 'w32)
       (progn
         (load "international/w32-ime")
         (w32-ime-initialize)
         (w32-ime-init-mode-line-display)
         (setq default-input-method "W32-IME")
         (setq-default w32-ime-mode-line-state-indicator "[--]")
         (setq w32-ime-mode-line-state-indicator-list '("[--]" "[あ]" "[--]"))))
       

• IMEパッチ自体は emacs-24.2-ime-2012-09-02.patch.tar.gzを元にしています。SVGサポートも含まれています。
  
• オリジナルではJPEG画像表示の時に減色されてしまうのですがフルカラー表示に強制しています。
• imagemagickパッケージはconfigure実行時に意図的に外しています。 含めてもビルドは完了すると思いますが動作が不安定な実行ファイルができあがる ようです(参考)。
• Cygwinでのビルドしか考えてませんのでconfigure.batはメンテしていません。
• Cygwin64には対応していません。

昼過ぎ起床。

先日のリソースリンクの続き。アプリアイコンがロードできていなかったのを 直したり。

org-modeの8.0.2が出ていたので試してみたり。今回のバージョンアップは 破壊的変更が入っているようで、色々とキーワードを変更する必要があったり。 ぼちぼち移行する感じで。

早くも無く遅くも無く。

先日、Cygwin64でemacs-w32をビルドした際に、リソースをリンクすると 実行できないバイナリが生成された件。emacs.rcの中で 「#ifdef WIN64」でmanifestファイルを切り替えていたのですが、 そもそもWIN64がdefineされているんだっけ？と思い、 windres の-Dオプションを使って明示的にWIN64をdefineしたリソースをリンク したところ、ちゃんと実行できるバイナリを生成する事ができました。

64bitのemacs-w32で Stanford Lucyの.plyファイル(508MB)を読み込んで みたのですが、問題無く読み込めました。いい感じです。 因みに、32bitのemacs-w32では、「Maximum buffer size exceeded」の メッセージが出てファイルの読み込みが途中でキャンセルされました。

マグネシウム電池。良さげな感じ。以前、 マグネシウムを燃やすことで得られる熱エネルギーから発電するような話を知った のですが、変換効率はかなり低いと考えられます。マグネシウム電池はその名の通り電池 なので変換効率が高いと思われます。 還元は太陽光を使う方法が有力なようなので、太陽光エネルギーを マグネシウムを介して電気エネルギーに変換する感じでしょうか。 すぐに電気エネルギーとして使用するならば、太陽電池で発電した方が一発変換 できるので変換ロスが少ない気もしますが、一時置きする点ではマグネシウム に還元する方が良いと考えられます。一番のカギは還元効率かも知れません。

具合が悪くて急速停止。

気持ち早めに帰着。

少し気になっていたCygwin64を入れてみる事にしたり。公式に公開はされていない？ ようですが、ミラーサイト からsetup64.exeを拾って、ダウンロード＆インストール。インストール先は c:/cygwin64になるようです。で、gccを入れるのに何故かdllが一部インストール されなくて使えず、手動で足りないDLLをインストールしたりしてそれとなく 使えるようになってみたり。

本題。x86_64対応のgdbを使うのに、x86の cygwinビルドなemacs-w32 では具合が 悪いと判断。そこでCygwin64の emacs-w32とgdbの組み合わせならうまくいくんじゃね？ という感じ。一応emacs-w32はパッケージがあったので、試してみたところ なんとなくうまくいきそうな予感。で、IMEパッチを手動であててemacs-w32を x86_64ビルドしてみる訳ですが、temacs.exeが生成できたものの動かない 実行バイナリが生成されて死亡。リソースをリンクするとダメっぽい。 リソースのリンクをやめれば一応起動できてIMEも動作する感じに。



でも、Subversionとか色々と 普段使っているツールのパッケージが存在していない為、 すぐにcygwin64に乗り換えるのは難しそう。当面、x86_64 デバッガを使いたく なったら、コマンドラインで我慢する感じかも。

Cygwin64の 一番の収穫はx86_64バイナリ用のlddコマンドが使えるようになった 点かも知れない(^^;

早くも無く遅くも無く。

gdb。Cygwinのx86_64-w64-mingw32クロス環境でビルドしてみるのは どうだろう？と思い試してみたり。ひとまずビルドはできたものの やっぱり状況変わらず。

process-coding-systemを utf-8-dos にすると画面は崩れなくなったものの、 なんだかうまく使えなかったり。Cygwinホストでx86_64-w64ターゲットに 動かせれば良いのかも知れませんが.....

気持ち早めに帰着。

gdc64。そういや先日の数学関数がうまく動かない件。version(Win64)で 発動するコードがダメなのですが、何故version(x86_64)ではなくversion(Win64) なのだろう？と思ったり。

DConf 2013。 ライブでストリーム視聴できないかなぁ？と思ったり。英語は全くダメなので スライドを見るだけですけど(^^;; 参加料を4万円くらい取るみたいなので ストリーム配信は無理か？ 因みに開催地である カリフォルニアのMenloParkは アメリカ西海岸なので、 日本時間(JST)の-16時間が現地時間(PDT)になるみたい。現地でam 9:00スタート だと日本では次の日のam 1:00なので、連休に重なっているし深夜から観ることが できるしで具合が良いのですけどね。

mingw64のgdb。Cygwinのemacs-w32からM-x gdbで使用すると何故か画面が崩れまくり の実行もなにやら怪しい感じになったり。Meadow3で実行する分には特に問題無く 使えるのですが、どうにもその差がよくわからなかったり。 gdb自身を野良ビルドして使ってみたのですがやっぱり画面が崩れる感じ。うーむ。

早めに帰着。

gdc64。手持ちコードに例外窓を開いてずっこけるものがあったり。 gdbがまともに使えないので、throw Exception()を挟みながらデバッグ したところ、数学関数のround()でずっこけているのが判ったり。 これもWin64ケースのコードで、特にアセンブラコードで実装されている訳では ないのですが何故かダメらしい。そんな訳でWin64ケースをコメントアウト して対応。数学関数はWin64ケースが全般的にダメな気がしたりも。

昼過ぎ起床。うー、寒い。

先日のビルドしたgdc,gccがCygwinのbashから使えない件。 libiconvとlibintlを64bit用にビルドしたのですが、そのDLLに パスが通っていないのが原因でした。事故しか起こらないので コンパイラ本体は他の共有ライブラリに依存して欲しくないところですが。

先日のリンクがうまくいかない件は以下の三点が原因でした。

.... lib/libgphobos2.a(memory.o): In function `_D2rt6memory16initStaticDataGCFZv':
.... libphobos/libdruntime/rt/memory.d:126: undefined reference to `_data_start__'
.... libphobos/libdruntime/rt/memory.d:126: undefined reference to `_bss_end__'
.... libphobos/std/math.d:2216: undefined reference to `_D3std4math4yl2xFNaNbNfeeZe'
collect2.exe: error: ld returned 1 exit status

$ gdc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW64\gdc64_031_2062_480\bin\gdc.exe
COLLECT_LTO_WRAPPER=c:/mingw64/gdc64_031_2062_480/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.8.0/configure --build=x86_64-w64-mingw32 --enable-languages=c,c++,d,lto --prefix=/mingw/gdc64_031_2062_480 --enable-threads --disable-nls --enable-sjlj-exceptions --disable-bootstrap --disable-multilib --disable-shared
Thread model: win32
gcc version 4.8.0 (GCC)

$ gdc -O2 iam.d ; ./a.exe
I am GNU
I am Windows
I am MinGW
I am Win64
I am X86_64

• libphobos/libdruntime/core/sys/windows/threadaux.d
  static void** getTEB() でのWin64時の version(GNU_InlineAsm)対応。 でも、どう書けばよいのか分からなかったので、エラーしないようにしただけ(^^;;;; gcc-4.6.xベースでは同等のコードは存在しませんでした。
  
  
• libphobos/libdruntime/rt/memory.d
  _data_start__などの定義対応。gcc-4.6.xベースのコードを移植して対応。
  
  
• libphobos/std/format.d
  version (Win64)時に 「static assert (false, "needs checking");」に 引っかかる部分多数。version (Win64)のコードをコメントアウトした。
  
  
• libphobos/std/math.d
  version (Win64)時に asm文を使っているコードと、一部のリンク時に参照できないシンボル を含んだコードをコメントアウトして、常にelse側が活きるようにした。 gcc-4.6.xベースの時には存在しなかったコード。
  

AM中に起床。

gdc64ビルド。なんだか少し困った事になっている気がしたり。

• TDM-gcc64は32bitアプリで、/usr/lib 下のlibiconv 32bit版に依存している。
• gdc64のビルドには/usr/lib 下に gettextの libintl 64bit版が必要。
• libintl 64bit版をビルドするには /usr/libの下に 64bit版のlibiconvが必要。
  ⇒つまり、/usr/libの下に 32bit版と64bit版の libiconvを同居しなくてはならない。でもそれは不可能。

早めに帰着。

gdc64ビルド。なにやらハマリまくり。先日libintlをビルドしなおして インストールしたのですが、これをリンクするとうまく立ち上がらない 実行ファイルが生成されたりしてどうしたもんか困ったり。

/mingw/libに32bitと64bitのバイナリが混在してしまってて、 一部のコマンド実行がずっこけてしまうようにもなり、それの復帰に時間を 吸われて終了。という訳で進展せず。

早くも無く遅くも無く。

手持ちコードのDMD2.062対応。一通り完了。

64bitターゲットのMinGW gdcのビルド。コンパイルエラーする点を直しながら 進めてみたのですが、結論としてTDM gcc-4.6.1を最新の gcc-4.7.1-3に アップデートする必要がありそう。でもまだダメ。

結局libintlがなにやらリンクできなかったのでビルドし直してインストール。 どうにか先に進めたり。

....でもやっぱり途中で停止。ぐふっ。

気持ち早めに帰着。

gdc。ベースバージョンをGDC-1b8647821fにしてビルドしてみたり。 どうやらいくつかの自前パッチはまだ必要そうで、以下の三点だけ適用しました (参考)。

1. 2012/12/22時点
   D言語ソース内で「2^^18」のようなPow式(累乗)を使用したとき、結果が0となるような アセンブラコードが生成されました。 gcc-4.6.3/gcc/d/dfrontend/constfold.cの一部を 少し前のコードに置き換えています。
   
   
2. 2012/12/22時点
   プロセス終了時にSegmentFaultで落ちる場合がある。 gcc-4.6.3/libphobos/libdruntime/gc/gcx.dを 少し改造しています。 ただし本当にこれで大丈夫かよくわかってません(^^;
   
   
3. 2013/03/10時点
   32bitターゲットでビルドした時にlong型の定数代入が化ける問題がありました。 gcc-4.6.3/gcc/d/d-codegen.ccを改造しました。
   

早くも無く遅くも無く。

gcc-4.8.0ベースのMinGW gdc。生成したバイナリがSegfaultする のですが、リンクで以下のようなメッセージが出ていたり。

$ gdc -v iam.d
Using built-in specs.
COLLECT_GCC=C:\MinGW\gdc031_2062_480\bin\gdc.exe
COLLECT_LTO_WRAPPER=c:/mingw/gdc031_2062_480/bin/../libexec/gcc/mingw32/4.8.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.0/configure --build=mingw32 --with-arch=i686 --enable-languages=c,c++,d,lto --prefix=/mingw/gdc031_2062_480 --enable-threads --enable-fully-dynamic-string --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-nls --disable-win32-registry --disable-symvers --disable-werror --enable-sjlj-exceptions --with-bugurl=https://bitbucket.org/goshawk/gdc/issue --disable-bootstrap --disable-shared --disable-libgomp --disable-libmudflap
Thread model: win32
gcc version 4.8.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=i386' '-march=i686'
 c:/mingw/gdc031_2062_480/bin/../libexec/gcc/mingw32/4.8.0/cc1d.exe iam.d -quiet -dumpbase iam.d -mtune=i386 -march=i686 -auxbase iam -version -iprefix c:\mingw\gdc031_2062_480\bin\../lib/gcc/mingw32/4.8.0/ -o C:\cygwin\tmp\cc7gvOU2.s
GNU D (GCC) version 4.8.0 (mingw32)
        compiled by GNU C version 4.6.3, GMP version 5.0.5, MPFR version 3.1.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU D (GCC) version 4.8.0 (mingw32)
        compiled by GNU C version 4.6.3, GMP version 5.0.5, MPFR version 3.1.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '-mtune=i386' '-march=i686'
 c:/mingw/gdc031_2062_480/bin/../lib/gcc/mingw32/4.8.0/../../../../mingw32/bin/as.exe -v -o C:\cygwin\tmp\ccVasD8g.o C:\cygwin\tmp\cc7gvOU2.s
GNU assembler version 2.23.1 (mingw32) using BFD version (GNU Binutils) 2.23.1
COMPILER_PATH=c:/mingw/gdc031_2062_480/bin/../libexec/gcc/mingw32/4.8.0/;c:/mingw/gdc031_2062_480/bin/../libexec/gcc/;c:/mingw/gdc031_2062_480/bin/../lib/gcc/mingw32/4.8.0/../../../../mingw32/bin/
LIBRARY_PATH=c:/mingw/gdc031_2062_480/bin/../lib/gcc/mingw32/4.8.0/;c:/mingw/gdc031_2062_480/bin/../lib/gcc/;c:/mingw/gdc031_2062_480/bin/../lib/gcc/mingw32/4.8.0/../../../../mingw32/lib/;c:/mingw/gdc031_2062_480/bin/../lib/gcc/mingw32/4.8.0/../../../;/mingw/lib/
COLLECT_GCC_OPTIONS='-v' '-mtune=i386' '-march=i686'
 c:/mingw/gdc031_2062_480/bin/../libexec/gcc/mingw32/4.8.0/collect2.exe -Bdynamic c:/mingw/gdc031_2062_480/bin/../lib/gcc/mingw32/4.8.0/../../../crt2.o c:/mingw/gdc031_2062_480/bin/../lib/gcc/mingw32/4.8.0/crtbegin.o -Lc:/mingw/gdc031_2062_480/bin/../lib/gcc/mingw32/4.8.0 -Lc:/mingw/gdc031_2062_480/bin/../lib/gcc -Lc:/mingw/gdc031_2062_480/bin/../lib/gcc/mingw32/4.8.0/../../../../mingw32/lib -Lc:/mingw/gdc031_2062_480/bin/../lib/gcc/mingw32/4.8.0/../../.. -L/mingw/lib C:\cygwin\tmp\ccVasD8g.o -lgphobos2 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt c:/mingw/gdc031_2062_480/bin/../lib/gcc/mingw32/4.8.0/crtend.o
Warning: resolving __D3std6traits41__T18hasElaborateAssignTS3std5stdio4FileZ8lvalueOfFNbNcNdZS3std5stdio4File1sS3std5stdio4File@secrel32 by linking to __D3std6traits41__T18hasElaborateAssignTS3std5stdio4FileZ8lvalueOfFNbNcNdZS3std5stdio4File1sS3std5stdio4File
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
Warning: resolving __D3std6traits55__T18hasElaborateAssignTS3std5stdio17LockingTextReaderZ8lvalueOfFNbNcNdZS3std5stdio17LockingTextReader1sS3std5stdio17LockingTextReader@secrel32 by linking to __D3std6traits55__T18hasElaborateAssignTS3std5stdio17LockingTextReaderZ8lvalueOfFNbNcNdZS3std5stdio17LockingTextReader1sS3std5stdio17LockingTextReader
Warning: resolving __D2rt8lifetime18__blkcache_storagePS2rt8lifetime7BlkInfo@secrel32 by linking to __D2rt8lifetime18__blkcache_storagePS2rt8lifetime7BlkInfo
Warning: resolving __D2rt8lifetime12__nextBlkIdxi@secrel32 by linking to __D2rt8lifetime12__nextBlkIdxi
Warning: resolving __tls_end@secrel32 by linking to __tls_end
Warning: resolving __tls_start@secrel32 by linking to __tls_start
Warning: resolving __D4core6thread5Fiber7sm_thisC4core6thread5Fiber@secrel32 by linking to __D4core6thread5Fiber7sm_thisC4core6thread5Fiber
Warning: resolving __D3std5regex274__T11memoizeExprVAyaa124_436f6465706f696e745365742e696e69742e61646428756e69636f6465416c7068616265746963292e61646428756e69636f64654d6e292e61646428756e69636f64654d63290a20202020202020202e61646428756e69636f64654d65292e61646428756e69636f64654e64292e61646428756e69636f6465506329Z11memoizeExprFNfZS3std8internal3uni12CodepointSet11initializedb@secrel32 by linking to __D3std5regex274__T11memoizeExprVAyaa124_436f6465706f696e745365742e696e69742e61646428756e69636f6465416c7068616265746963292e61646428756e69636f64654d6e292e61646428756e69636f64654d63290a20202020202020202e61646428756e69636f64654d65292e61646428756e69636f64654e64292e61646428756e69636f6465506329Z11memoizeExprFNfZS3std8internal3uni12CodepointSet11initializedb
Warning: resolving __D3std5regex274__T11memoizeExprVAyaa124_436f6465706f696e745365742e696e69742e61646428756e69636f6465416c7068616265746963292e61646428756e69636f64654d6e292e61646428756e69636f64654d63290a20202020202020202e61646428756e69636f64654d65292e61646428756e69636f64654e64292e61646428756e69636f6465506329Z11memoizeExprFNfZS3std8internal3uni12CodepointSet4slotS3std8internal3uni12CodepointSet@secrel32 by linking to __D3std5regex274__T11memoizeExprVAyaa124_436f6465706f696e745365742e696e69742e61646428756e69636f6465416c7068616265746963292e61646428756e69636f64654d6e292e61646428756e69636f64654d63290a20202020202020202e61646428756e69636f64654d65292e61646428756e69636f64654e64292e61646428756e69636f6465506329Z11memoizeExprFNfZS3std8internal3uni12CodepointSet4slotS3std8internal3uni12CodepointSet
Warning: resolving __D3std5regex9trieCacheHxS3std8internal3uni12CodepointSetS3std8internal3uni22__T13CodepointTrieVi8Z13CodepointTrie@secrel32 by linking to __D3std5regex9trieCacheHxS3std8internal3uni12CodepointSetS3std8internal3uni22__T13CodepointTrieVi8Z13CodepointTrie
Warning: resolving __D3std5regex63__T11memoizeExprVAyaa19_5472696528776f726443686172616374657229Z11memoizeExprFNfZS3std8internal3uni22__T13CodepointTrieVi8Z13CodepointTrie11initializedb@secrel32 by linking to __D3std5regex63__T11memoizeExprVAyaa19_5472696528776f726443686172616374657229Z11memoizeExprFNfZS3std8internal3uni22__T13CodepointTrieVi8Z13CodepointTrie11initializedb
Warning: resolving __D3std5regex63__T11memoizeExprVAyaa19_5472696528776f726443686172616374657229Z11memoizeExprFNfZS3std8internal3uni22__T13CodepointTrieVi8Z13CodepointTrie4slotS3std8internal3uni22__T13CodepointTrieVi8Z13CodepointTrie@secrel32 by linking to __D3std5regex63__T11memoizeExprVAyaa19_5472696528776f726443686172616374657229Z11memoizeExprFNfZS3std8internal3uni22__T13CodepointTrieVi8Z13CodepointTrie4slotS3std8internal3uni22__T13CodepointTrieVi8Z13CodepointTrie

$ cat TLS_test.c
__thread int a;
int b;

int main() {
   return a = b;
}

$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\gdc031_2062_480\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/gdc031_2062_480/bin/../libexec/gcc/mingw32/4.8.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.0/configure --build=mingw32 --with-arch=i686 --enable-languages=c,c++,d,lto --prefix=/mingw/gdc031_2062_480 --enable-threads --enable-fully-dynamic-string --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-nls --disable-win32-registry --disable-symvers --disable-werror --enable-sjlj-exceptions --with-bugurl=https://bitbucket.org/goshawk/gdc/issue --disable-bootstrap --disable-shared --disable-libgomp --disable-libmudflap
Thread model: win32
gcc version 4.8.0 (GCC)

$ gcc TLS_test.c
Warning: resolving _a@secrel32 by linking to _a
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups

$ ./a.exe
Segmentation fault

$ gdc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\gdc031_2062_480\bin\gdc.exe
COLLECT_LTO_WRAPPER=c:/mingw/gdc031_2062_480/bin/../libexec/gcc/mingw32/4.8.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.0/configure --build=mingw32 --with-arch=i686 --enable-languages=c,c++,d,lto --prefix=/mingw/gdc031_2062_480 --enable-threads --disable-nls --enable-sjlj-exceptions --disable-bootstrap
Thread model: win32
gcc version 4.8.0 (GCC)

$ gdc -O iam.d

$ ./a.exe
I am GNU
I am Windows
I am MinGW
I am Win32
I am X86

早くも無く遅くも無く。

gcc-4.8.0をベースにしたgdcのMinGWビルドを試してみたり。 venix1氏のパッチはgithubには置かれていなくて、 bitbucket に置かれているバイナリに含まれていました。 ベースとなるgccは4.8のスナップショット向けのパッチのようですが、 リリース版の4.8.0にもそのままあてられました。

で、ビルドしてみたところ、途中かなり怪しいのですが libgphobosのビルドまで できたり。make installしてHelloWorldレベルのソースをコンパイル してみたところ、リンク時にワーニングメッセージが大量に出ますが 実行ファイルの生成はできたり。そして実行してみる訳ですが Segfaultする実行ファイルだったりしてションボリ。

bitbucketのバイナリを試しに使ってみたのですが、何故かアーカイブに 含まれるどの実行ファイルもなにやら正しく実行できなくて全く 用事にならなかったり。うーむ。

昼過ぎ起床。風が強いなぁ。

ちょろり本屋に。「プログラミング言語D」を購入。そういや発売直後くらい は全く見ることができなかった「Land of Lisp」がやたら置いてあったり。 結構売れているのでしょうか。

D言語本。2010年6月に発売された「The D Programming Language」の邦訳版 なので、DMD2.047とかが出たよりも前のDMDがベースになっているのかと。 この頃はgdcは完全に追従が止まっていて、DMD2.014ベースのgdcを使って いました。メンテナンスが再開され始めたのに気づいたのが 2010/08/27なので、 gdcは結構ゴタゴタしていた時期だったかも。

さておき、結構詳しく書かれているので新しい発見があるかも 知れないし無いかも知れないそんな予感。ぼちぼち読み進める感じで。

起きたら午後もいい時間。

calcとgnuplotの連携でグラフを描かせてみた時のメモ。

• 「g D」で描画デバイスを指定。Cygwinのgnuplotはグラフ表示にXが必要 になるので、このコマンドで描画デバイスを「png」や「svg」にセットする。
• 「g O」で描画結果のファイル名を指定。適当に「/tmp/xxx.png」や「/tmp/xxx.svg」とかで。
• 「g N」でサンプリング数を変更。初期プロットはポイント数が少ないので 適当に増やします。
• 「g g」でgrid描画を制御します。
• 「g C」でgnuplotのその他コマンドを実行。例えば「set pm3d」とか「set hidden3d 」とか。
• 「g f」で2次元グラフの描画。「g F」で3次元グラフの描画。

2:  [-360 .. 360]
1:  sin(x)

気持ち遅めに帰着。

電卓代わりのちょっとした計算は、Emacsのスクラッチバッファに LISPをちょろっと書いて答えを求めることがあるのですが、 馴れないと式が判りにくかったり、大き過ぎる値は扱えなかったりと オールOKという感じではありませんでした。何か無いかと探って みたら、calc-evalなる関数がその希望にかなうのを知ったり。

(calc-eval "123+456/789") ;式通りに書けば良い
"123.577946768"
(calc-eval "123^40")      ;多倍長整数もいけます
"394643048784752396342497257507364878606804197268391876404988552236061387660472578401"
(calc-eval "123.0^456")
"9.92500687722e952"

1:  (x + 1) (x + 2) (x + 3)   ; a x で展開(下の式に)
1:  x^3 + 6 x^2 + 11 x + 6    ; a f で因数分解(上の式に戻る)

1:  1234567890                ; k f で素因数分解
1:  [2, 3, 3, 5, 3607, 3803]  ; ←───結果

早めに帰着。

メガデモで少し気になったのがあったり。

• Gaia Machina
• Turtles all the way down

$ cat hello.c
#include <stdlib.h>
#include <stdio.h>

int main()
{
  printf("Hello World.") ;
  return(0) ;
}

$ gcc -O2 hello.c -o hello.exe ; strip hello.exe ; ls -l hello.exe
-rwxr-xr-x 1 TANE None 4622 4月  11 23:54 hello.exe

早めに帰着。

あまりの眠さに急速停止。

気持ち早めに帰着。

ちょろり調べごと。

早めに帰着。

gdc。trunkのgcc-4.9向けの変更が gcc-4.8.0へのマージされている模様。 まだ4.8.0と4.9開発版との差がほとんど無いからマージも比較的 簡単なのかも知れません。そういやgcc-4.8.0ベースのMinGW向けgdcは まだ来ないなぁ。

昼頃起床。天気は良いけど風がやたら強い。

洗濯したり掃除したり。ちょろりお出かけ。

今のPCにはフロントパネル側にヘッドホン端子が無いのですが、 なんだか不便なのに今頃気づいたり。一応スピーカーにヘッドホン端子は 付いているのですが、ホワイトノイズがずっと乗っててイマイチだった ので、USB→オーディオ変換アダプタを購入してみたり。 ノイズも無くて良い感じ。USBと背面のスピーカージャックとは排他になる ので、スピーカーから音を出したければ変換器のUSB接続を外せば 切り替わるという感じ。

      ┌PC──┐                     →   ┌PC──┐
      │      │    ┌─┐           →   │      │              ┌─┐
      │ Audio◎──┤SP│ ノイズ多  →   │ Audio◎───────┤SP│
      │      │    └┬┘  ↓       →   │      │              └─┘
      │      │      │  ┌─┐     →   │      │  ┌──┐    ┌─┐
      │   USB◎      └─┤HP│     →   │   USB◎─┤変換◎──┤HP│
      └───┘          └─┘     →   └───┘  └──┘    └─┘

昼過ぎ起床。

雨が降り始める前にちょろりお買い物。

Fedora上で gcc-4.9スナップショットベースのgdcをビルドしてみたり。ひとまず エラー無くビルド完了。HelloWorldレベルの簡単なソースのコンパイル＆実行は 問題無さげ。

そういや家では慣れる為に、ターミナルはemacs-w32(on Cygwin)上のterm+を使用してみて います。ただ、現在使用しているemacs-w32は普段やらないことをやると 稀に無反応になってしまう事があります。そうなった場合、ターミナルが お亡くなりになってしまうので、例えばリモートマシンでgdcのビルド作業中で あっても実行自体が停止するしログも全て消失してしまいます。 そこで、リモートマシンにログインした場合はscreenを使うようにしています。 イメージ的には次のような感じでしょうか。

        ┌─emacs-w32(ローカルホスト) ───────────┐
        │┌─term+(ローカルホストbash) ─────────┐│
        ││┌─ssh(リモートマシンに接続) ───────┐││
        │││┌─screen(リモートマシンで実行)────┐│││
        ││││┌─各種作業(リモートマシンshell) ─┐││││
        │││││                                  │││││
        ││││└─────────────────┘││││
        │││└───────────────────┘│││
        ││└─────────────────────┘││
        │└───────────────────────┘│
        └─────────────────────────┘

• ローカルマシンでemacsがお亡くなりになってもリモートでの作業は継続される。 screenを再接続(リアタッチ)すれば復帰できます。
• emacsのターミナル表示が遅いのを隠蔽できる。screenで何も表示しないウインドに切り替えておけば、 例えばgdcのビルド時間が表示につられて遅くなるといった事が無くなる。

• screen操作を行うのにキー入力のストローク数が多くなる。 例えばscreenのprefixを C-tにしてあった場合、term+からscreenに対してCopyモード への切り替え(この場合 C-t C-[)を実行するには「C-q C-t C-q C-[」てな感じで C-qでエスケープする操作が必要になります。

早くも無く遅くも無く。

調べ事をして終了。

早めに帰着。

あまりの眠さに急速停止。

早めに帰着。

カールじいさんの空飛ぶ家を観たり。結構強引な話の持って行きかた をしている気がしなくもありませんでしたが、面白かったと思います。

早めに帰着。

ちょろり調べごと。

あまりの眠さに急速停止。

早めに帰着。

あまりの眠さに急速停止。