libc6 (glibc)をgcc-7でbuildする (@Debian Sid)

Debian Sidのgcc-7 (7.1)でlibc6 (glibc)をsource packageからbuildしようとすると、-werrorの効果でwarningがerror扱いになり途中で止まってしまう。これは使い方によっては有用なoptionだが、取り敢えずbuildを通したい時には面倒なので細工してみる。

glibcの./configure scriptには--disable-werrorという便利なoptionがあるのでこれを与えれば良さそうだと分かる。問題は、dpkg-buildpackageでbinary packageをbuildする際にどのようにこのoptionを./configureに渡すか。

まず最初に思い付いたのがdebian/rulesに適当な記述を加える方法だが、./configureに直接optionを渡せそうな設定項目が無かった。

次に目を付けたのがdebian/sysdeps/amd64.mkで、これはamd64 (aka. x86_64, x64) platformにて利用されるbuild script。中身を見てみると、丁度利用できそうな部分があったので次のように書き換え:

extra_config_options = --enable-multi-arch

↓

extra_config_options = --enable-multi-arch --disable-werror

あとはいつも通り、top levelで:

 % dpkg-buildpackage -us -uc -B -d -rfakeroot -j8

あたりを発行しbinary packageをbuild。

Intel CPUの殻割りとリキプロ化

今更ながら手持ちのCPU 2つを殻割り (delid)し、TIMをLIQUID PROに変えてみた。

動機

メインマシンの6700KでCPUに負荷を掛けるとパッケージ温度が70度Cを超えてしまい夏場の使用が不安である。

Shuttleのキューブ型ケースを利用しているのでCPUクーラーの交換は難しい。そこで、いわゆる「グリスバーガー」を解消すれば状況が改善とすると考えて殻割りすることにした。

定格運用でも、いわゆる「熱ダレ」(thermal throttling)が起き難くなることが期待できる。

使った物

対象CPU

• Intel Core i5-3330
• Intel Core i7-6700K

3330はoverclockできない（マザーボードもH61）ので殻割りする意味は余りないが、いきなり6700Kで作業するのが怖かったので練習がてらやってみた。

事前調査 (3770Kと6700Kについて)どちらもヒートスプレッダ内部にチップコンデンサ等が実装されていないので、難易度は低いと思う。

道具類

• カッターナイフ (今回はその辺にあったものを利用したので刃は厚さ0.39mm。OLFAから壁紙カット用として販売されている0.2mmぐらいの薄い刃を勧める)
• テレホンカード (厚さ0.27mm。ボロボロになるので使用済み、もしくは不要なポイントカードなどがあればそちらを勧める)
• LIQUID PRO (液体金属。もしくはクマメタル)
• ブラックシーラー (ゴム系接着剤。本来は車のボディの補修に使う物だが、殻割りする人々の間でも広く用いられている)
• マスキングテープ (裏側の電極やチップコンデンサなどの保護のために利用。この用途にセロハンテープなどを使うと接着剤が残るのでNG。一方でゴミ取りには少々接着力不足)
• 綿棒 (CPUグリスやダイに残ったTIMを掃除する、LIQUID PROを塗るなど)
• 爪楊枝 (基盤やヒートスプレッダの内側に残った接着剤を擦り取ったり、ブラックシーラーを塗る時に使う)
• ティッシュペーパー (手に入るならキムワイプとかの方が良いだろう。一応のためダイは綿棒で掃除した)
• 燃料用アルコール (毒性の問題があるので無水エタノールを用いた方が良いが代用)
• 金属板 (静電気でCPUを壊さないように作業場として利用。気休め)
• エアダスター

作業を終えて、あったら良かったなと思ったもの:

• 絶縁テープ (6700Kはヒートスプレッダ内の基盤に剥き出しの電極があるのでそこを覆う。注文したが届いていないので今回はブラックシーラーで代用)
• セロハンテープ (ヒートスプレッダの位置を固定したり、飛び散った接着剤を掃除するのに便利。今回はマスキングテープで代用)

手順

• CPUのヒートスプレッダの隅から基盤との間にカッターの刃を入れる
• 或る程度入ったらテレホンカードやポイントカードを差し込んで接着剤を切っていく
• TIMと接着剤を除去してLIQUID PRO (もしくはクマメタル)をダイの上に塗る
• ヒートスプレッダの周囲にブラックシーラーを塗り元の位置に固定
• 乾燥させて固定する
• マザーボードに取り付けて動作確認

感想

• 最初にカッターの刃を入れる時が一番緊張する。角度を間違えると基盤を傷付け故障の原因になるので入らなくても無理をしない
• カッターだけでやる人もいるがテレホンカード類を用意した方が安全。或いは殻割り専用ツールを使う
• 3330でも6700KでもTIMは完全に乾燥してボロボロになっていた。これは冷えない訳だ
• ヒートスプレッダを綺麗に戻すのは結構難しいが、最初に写真を撮っておいてそれを参考にすると良いと思う。最終的には取り付けられれば問題ない
• 本来なら或る程度乾燥の為に時間を置くべきだが、壊していないか確認したくなり早速取り付けてしまったが今の所問題なく動いている

結果

試しに負荷を掛けてみた。室温は23度C程度。CPU温度はpackage temperature。

i5-3330

マシン構成

• OS: Microsoft Windows 10 (64bit)
• CPU: Intel Core i5-3330
• Mem: DDR3-1333 16GBtyes
• GPU: HIS (AMD RX480)
• HDD1: WD5000AAKX (500GBytes)
• HDD2: WD30EZRX (3TBytes)
• 適当なケースがなくバラック状態

主にゲーム用として使っているのでCINEBENCH、手持ちのゲームなどを試してみたが60度Cを超えない。

手持ちのソフトはCPUよりGPUパワーを必要とするタイトルばかりなので、AMD RX480がbottleneckになっている感じ。当然ながらCPU負荷も温度も上がらない

6700K

マシン構成

• OS: Linux (Debian/Sid) w/ Linux kernel 4.10.10 (64bit)
• CPU: Intel Core i7-6700K
• Mem: DDR4
• GPU: Onboard
• SSD: SATA 512GBytes
• HDD: WD 8TB

Linux machineで行う負荷の高い作業は:

• Source codeからのbuild (Linux kernel, Mozilla Firefox, etc)
• 3D graphics (iGPU)を多用するsoftware (Stellarium, Celestia, etc)
• ffmpegなどによる動画encodingなど

※以下、PC内温度32度C

• Linux kernel (v4.10.10)、Mozilla Firefox (55.0a1, 54.0a2)などをbuildして60度Cを超えない
• Celestia, Stellariumなどを実行しても40度Cを超えない
• ffmpegでのsoftware encoding (h264)では最大63度C。QSVを利用したtranscoding (h264, rescaling)なら40度Cを超えない

これからの展望

巷で話題のAMD Ryzenならソルダリングなのでこんな手間は必要ない。

利益率を上げる為に行われる製品の製造プロセスの見直しは必要だが、さすがにやってい良いことと悪いことがあると個人的には考えている。Intelは（せめてK付きとかは）ソルダリングに戻してほしいし、AMDにはこのままソルダリングで続けて欲しい。

NieR:Automata Original Soundtrackのヨコオタロウ氏のメッセージをshellとnkfでdecodeする

NieR:AutomataのOriginal Soundtrackに付属するブックレットに、ディレクターであるヨコオタロウ氏のメッセージが16進数で記載されており、（大抵の人間は）そのままでは読めない。

ネット上では既に多くの先人達が解読しており、URL等で使われる「パーセントエンコーディング」であると知られている。これをshell scriptとnkfを使ってdecodeしてみる。

なお、メッセージの内容については一切触れない。

実際の作業

* 写真を取る／スキャンする
* OCRで文字に変換
* 16進数文字列→日本語

最も面倒だったのがOCRで文字に変換する部分だった。写真の撮影のしかたが悪かったのもある。今回はGoogle driveにuploadしてOCRにかけ、目視で比較して修正するという方法を取らざるを得なかった。

一旦文字列になってしまえば後はnkfに掛けるだけである。

% echo '\n＜16進数の文字列＞' | fold -s2 | tr '\n' '=' | nkf -WwmQ

まず、foldで2文字ごとに区切る。次に、trで改行コードを'='に変換する。最後にnkfに文字列を渡してdecodeする。

参考URL

* [shell で4文字づつ切り出す方法 - Qiita](http://qiita.com/mapk0y/items/51e6765add9b79264714)
* [40.Linuxのコマンドから行うURLエンコード、URLデコード](http://www.garunimo.com/program/linux/linux40.xhtml)
* [パーセントエンコーディング - Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%BC%E3%82%BB%E3%83%B3%E3%83%88%E3%82%A8%E3%83%B3%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0)

SwissMicros DM15Lのfirmware v22がreleaseされていた

(2017-06-16更新) Firmware V23がreleaseされていたのでupgrade (詳細はhttp://typeinf-memo.blogspot.com/2016/07/swissmicros-dm-15lfirmware-upgrade.htmlにて)。

WP 43Sのhardwareを開発していることについて何か書いてないかとSwissMicrosのwebsiteを覗いてみたら、DM15L (及びその他製品の) firmware v22がreleaseされていた。

前回同様に無事update完了。WP 34Sもこれくらい楽だったら良かったのだが……。

Debian sid/experimentalのgcc-6/gcc-7でLinux kernelがbuildできない問題とその対応

Linux kernel 4.10.1がreleaseされたのでbuildしようとしたら……

>   LD      vmlinux
> kernel/built-in.o: In function `update_wall_time':
> (.text+0x5fa0a): undefined reference to `____ilog2_NaN'
> Makefile:969: recipe for target 'vmlinux' failed
> make[1]: *** [vmlinux] Error 1

つい数日前 (2/20)はbuildできた4.10.0もダメだった (@gcc-6, gcc-7)。

`/var/log/aptitude`を確認してみた所、Sidのgcc-6 (6.3.0-8)を2/22に、experimentalのgcc-7 (7-20170221-1)を2/24にそれぞれ更新していた。

"linux ____ilog2_nan"でGoogle検索したら、次のpageを発見:

詳しくはよく分からないが、Linux kernel内部で利用されている`ilog2()`をcompileする際にGCCのtree-optimizationで問題が発生している模様 (cf. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785)。どうやらkernel側のbugっぽい。

既にworkaroundがあり`include/linux/log2.h`へのpatch (cf. http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/462224.html)を当てた所buildできた。

Debian unstableでFirefox 50.1.1 (release)とFirefox 52.0a2 (aurora)のbuildが失敗する

2017-01-18追記: Firefox 51.0で修正されbuild可能になった

Debian unstableでFxをsourceからbuildするとconfigureの段階で転ける。

> cannot determine icu version number from uvernum.h header file

libicu関連。いつからだったのか分からないが、libicuのversion情報が取得できないせい (因みにunstableが57でexperimentalが58。stableは55)。

firefox-release (50.1.1)は56にdependしており、firefox-aurora (52.0a2)は58にdependしている。何れもsystemにinstallされているlibicuを見付けられず、そこでbuildが止まる。

取り敢えずworkaroundを発見したので暫く様子見。

firefox-aurora

experimentalのlibicu58関連にupgrade。libicu57は別の色々なpackagesがdependしているのでそのまま。

build/autoconf/icu.m4を変更 (72行あたり):

    version=`sed -n 's/^[[:space:]]*#[[:space:]]*define[[:space:]][[:space:]]*U_ICU_VERSION_MAJOR_NUM[[:space:]][[:space:]]*\([0-9][0-9]*\)[[:space:]]*$/\1/p' "$icudir/common/unicode/uvernum.h"`

↓

    version="58"

icuのversionを調べるscriptが何故か失敗する (consoleでやると上手くいくのだが)ので、versionを決め打ちする (この場合はexperimentalの58)。

firefox-auroraについてはこれだけでbuildが通る。

firefox-release

firefox-release (50.1.1)は少々面倒:

* build/autoconf/icu.m4を変更 (versionを58で決め打ち)
* cp -i /usr/include/unicode/uvernum.h /usr/include/unicode/uversion.h intl/icu/source/common/unicode/ → localで持っているversionが古いのでsystemのlibicu58を使う (一応のため)
* cp -i /firefox-aurora/config/external/icu/data/icudt58l.dat config/external/icu/data/ → icudt58l.datが無いとbuildが転けるのでauroraの(libicu58用)をcopyしておく

これで取り敢えず./mach buildが通って、./mach runで動いた。ミソは多分icudt58l.datをauroraから貰って来る所だと思う。

Emacsのdiff-modeでauto-refinesの仕様変更とworkaround

diff-modeの移動に関する変更があった後、間も無く別のcommit (e5ef59b87da5c2ddfa22f7342efe29b3eea6ed97)でauto-refinesに関する仕様も変更されていた。

移動が確実に行われた時のみ、細かい変更点 (refines)をcoloringする挙動になった。これに伴いauto-refinesの関連codeが別の場所に移され、以前取った方法では移動するだけではrefinesへのcoloringが適用されなくなった。

対策として、「Emacsのdiff-modeでdiff-hunk-prev/next等の挙動が変更された」で紹介したcodeをベースにして以下のように変更し解決した:

(with-eval-after-load "diff-mode"

  (defun my-diff-hunk-next (&optional count)

    (interactive)

    (diff-hunk-next count nil)

    (diff-refine-hunk))

  (defun my-diff-hunk-prev (&optional count)

    (interactive)

    (diff-hunk-prev count nil)

    (diff-refine-hunk))

  ;; key bindings

  (define-key diff-mode-shared-map "n" 'my-diff-hunk-next)

  (define-key diff-mode-shared-map "p" 'my-diff-hunk-prev))

やっていることは、それぞれのfunction内で移動するためのfunctionを呼び出した後に、coloringする為のdiff-refine-hunkを呼び出すだけである。