atton.blog: Homebrew

ラベル Homebrew の投稿を表示しています。すべての投稿を表示

2020/04/19

Homebrew で awscli を upgrade して、依存の keg-only python@3.8 を link する

Homebrew が提供する awscli が 2.0 になる前辺り、必要な python が python@3.8 になりました。
awscli を upgrade する際、 python を消して python@3.8 を使うようにしたログです。

環境(ブログ作成時)

OS: macOS Mojave 10.14.6
Homebrew: 2.2.13-74-gecea0e5

homebrew-core (git revision eb6d; last commit 2020-04-19)
python: Python3.7.7
python@3.8: Python 3.8.2

awscli: aws-cli/2.0.8 Python/3.8.2 Darwin/18.7.0 botocore/2.0.0dev12

keg-only formula と Homebrew の install 事情

Homebrew は元々、 /usr/local/bin へ直接 formula を install しません。

/usr/local/Cellar などの PATH に install して、そこから symlink を貼ります。

その中で key-only formula は「install しても /usr/local/bin に link しない」 formula です。

今回は python@3.8 が keg-only に指定されています。理由として executable の衝突回避が挙げられます。

前提として、現時点で Homebrew が提供している python は 3.7 系列
python が存在する環境に python@3.8 も installすると /usr/local/bin/python3 が重複する
/usr/local/bin/python3 を 3.7 系列に譲るために、 3.8 は keg-only として link しない

という感じかと思われます。

keg-only formula を link する前の確認

link の前に、念の為 python が使われていないか、以下のコマンドでチェックします。

$ brew uses --installed python

何も出力されない場合は install 済みの formulas 全てにおいて python を使っていません。
出力がある場合、その formula は python を使っています。 3.8 の link は止めた方が良いでしょう。

python@3.8 を /usr/local/bin に link する

上記のチェック時、私の環境では出力が無かった為 python@3.8 を link する事にしました。
なお、 keg-only formula を link する場合は --force が必要です。

$ brew upgrade awscli

依存関係で python@3.8 が install される

$ brew link --force python@3.8
$ which python3 aws
- /usr/local/bin/python3
- /usr/local/bin/aws
$ python3 -V

Python 3.8.2

$ aws --version

aws-cli/2.0.8 Python/3.8.2 Darwin/18.7.0 botocore/2.0.0dev12

これで python3 と awscli が upgrade できました。良し良し。
ちなみに homebrew-bundle では、 link: true を付けると link してくれます。

2019/12/21

tmux 3.0a の window 分割線を ascii character にする

2019/12/01 に tmux の version 3.0a がリリースされました。
いつも通りに分割線を multibyte character から ascii にする作業をします。
過去の作業ログは 2.9a や 2.8 や 2.7 など。そもそもの問題についてはこの記事にあります。

環境

OS: macOS Mojave 10.14.6
tmux: 3.0a-border-ascii ( 9664700184f23ec828768c8aceac248dc2efffdc )
Homebrew: 2.2.1-76-gaf98c15
Homebrew/homebrew-core: (git revision d0305; last commit 2019-12-20)
Font: Ricty 3.2.2

インストール方法

$ brew install --HEAD atton/customs/tmux

でインストールできます。

今回の変更

tmux は window や pane を表示するための文字情報を tty-acs.c に持っています。

なので、毎度この定義を修正する事で対応しています。

2.9a の時等は tty-acs.c に変更が無かった為、過去の commit の cherry-pick のみで目的が達成できました。

が、今回は修正が入っているので cherry-pick をすると conflict します。
conflict を解消する形で対応しても良いのですが、今回は新しく修正用の commit を作ることにしました。

過去のパッチを参考にすると、置換が必要な文字とその対応関係は

j,k,l,m,n,t,u,v,w が "+"
x が "|"
q が "-"
~ が "*"

のようです。これらを元に tty-acs.c を修正。make すると今まで通り動きました。
もちろん後から何か踏む可能性はありますが、今の所問題は発生していません。
ということで tmux のソースコードの更新は以上。
あとは branch 名を homebrew の atton/customs 用に付けてあげればおしまいです。

formula の更新は本家 tmux の --HEAD 版の定義を借りて、branch 名を指定すればOK。

と、いうことで tmux 3.0a-border-ascii の更新ログでした。

おまけ

分割線の定義を間違えると、分割した瞬間に tmux が crash します。こわい。

きちんと定義できれば以下のように割りたい放題しても動きます。

2019/12/15

AquaSKK で Sticky Shift を使う

私は普段、mac で日本語入力をする時は AquaSKK を使っています。
AquaSKK は version 4.7.0 から Stickey Shift が実装されたようなので設定してみました。

環境

OS: macOS Mojave 10.14.6
Homebrew: 2.1.15-63-g090259b
Homebrew/homebrew-cask: (git revision ec6b9; last commit 2019-10-26)
AquaSKK: 4.7.0
neovim: 0.4.2
eskk.vim: 207d05cd

AquaSKK の install

homebrew-cask に formula があるので

$ brew cask install aquaskk

で Install できます。

SKK とは

日本語のかな漢字変換プログラムの一つです。

形態素解析を行なわず、漢字に変換、もしくは送り仮名付きの漢字の変換箇所をユーザが指定して入力します。

何を言っているのかさっぱりな感じもあるので、具体的な例を見ていきましょう。

漢字変換

例えば『漢字』と入力したい場合、「ことえり」や「Google 日本語入力」では

kanzi<space> または kanji<space>

と入力します。

そして SKK では、変換を開始する入力を大文字のアルファベットで指定します。よって

Kanzi<space> または Kanji<space>

と入力します。

送り仮名付き漢字変換

さて、次は『感じ』と入力したい場合を想定します。

「ことえり」や「Google 日本語入力」では変わらずに

kanzi<space> または kanji<space>

と入力します。また、その時の変換候補に『漢字』が出ることもあるでしょう。

SKK では送り仮名付きの漢字変換の時の変換箇所も大文字アルファベットで指定します。つまり

KanZi<space> または KanJi<space>

と入力します。そうすると、「感じ」「観じ」といった送り仮名付きの変換候補しか出ません。

さらに言えば、先程の『漢字』の入力について

Kanzi<space> または Kanji<space>

と入力した場合の変換候補は「漢字」「幹事」「監事」といった、送り仮名無しの候補しか出ません。

これが結構便利で、「送り仮名あり、送り仮名無し」の入力に関しては誤字が少なくなります。

横道: 形態素解析をしない、ということ

例に上げたように、漢字入力の際や送り仮名付きの漢字入力では SKK にはメリットがあります。

しかし、変換のポイントを自分で指定するため

これは漢字の入力のテストです

といった入力は一度にはできません。

「ことえり」や「Google 日本語入力」では全てのアルファベットを入力した後、先頭から少しずつ変換することができます。

なので、それぞれ得手不得手がある、と思った方が良いかと思われます。

Sticky Shift とは

さて、ここまで来ると Sticky Shift のお話ができます。

Sticky Shift とは、変換の指定ポイントを大文字のアルファベットでは無く、特定の文字で指定する方法です。

例えば、';' を設定した場合、先程の「漢字と感じ」は

;kanji<space>to;kan;ji

と入力できます。

一見冗長ですが、慣れると便利です。

加えて、大文字入力が必要無いので Shift Key を使わずに入力を完結させることができます。
なお、eskk.vim では default で ';' Key が Sticky Shift 用の文字として実装されています。

Sticky Shift の設定

keymap.conf を編集する、と github の wiki に記述されています。

そしてkeymap.conf については AquaSKK の wiki に記述があります。

ので設定してみましょう。大元の設定をコピーして追記します。

なお、コピー先の ~/Library/Application\ Support/AquaSKK については、AquaSKK を install した時に作られています。

なので

$ cp /Library/Input\ Methods/AquaSKK.app/Contents/Resources/keymap.conf ~/Library/Application\ Support/AquaSKK

を実行してコピー。

そして ~/Library/Application\ Support/AquaSKK/keymap.conf に

StickyKey ;

を追記します。

その後、AquaSKK のプロセスを殺すか、reboot 等で AquaSKK が再起動すれば、Sticky Shift が有効になっているはずです。

めでたしめでたし。

参考

2019/10/06

q を使って CSV ファイルに SQL を発行する

"q" という、CSV や TSV に SQL をに発行できるコマンドがあります。
便利なのですが、名前がググりづらいことこの上無い感じですね。

環境

OS: macOS Mojave 10.14.6
Homebrew: 2.1.12-8-gfd9a09e

homebrew-core: (git revision 5b99; last commit 2019-10-05)

q: 1.7.4

インストール方法

Homebrew で fomula が用意されているので

$ brew install q

でインストールできます。

実行例

例えば、以下のような "servant.csv" があったとして

以下のように SQL が発行できます。

select

$ q -d, -H 'select * from servant.csv ;'

1,Altria Pendragon,saver,5
2,Altria Pendragon (alter),saver,4
3,Altria Pendragon,archer,5
4,Altria Pendragon,lancer,5
5,Altria Pendragon (alter),lancer,4

count

$ q -d, -H 'select count(*) from servant.csv ;'

limit

$ q -d, -H 'select * from servant.csv limit 2;'

1,Altria Pendragon,saver,5
2,Altria Pendragon (alter),saver,4

distinct

$ q -d, -H 'select distinct(name) from servant.csv ;'

Altria Pendragon
Altria Pendragon (alter)

where

$ q -d, -H 'select id,name,class from servant.csv where rarity = 5;'

1,Altria Pendragon,saver
3,Altria Pendragon,archer
4,Altria Pendragon,lancer

order

$ q -d, -H 'select * from servant.csv order by rarity;'

2,Altria Pendragon (alter),saver,4
5,Altria Pendragon (alter),lancer,4
1,Altria Pendragon,saver,5
3,Altria Pendragon,archer,5
4,Altria Pendragon,lancer,5

distinct + count

$ q -d, -H 'select count(distinct(name)) from servant.csv ;'

なお、付けているオプションは

-d (--delimiter) 今回は csv なので ',' が delimiter です。
-H (--skip-header) 今回は一行目に header があるので、それは値としてみなしません。

と、いうことは header が無い場合も想定していると思われます(やったこと無し)。

です。--help は貴重な情報源。

まとめ

と、いう感じで、"q" を使うと CSV を色々いじったりできて便利です。

ちなみに、 Office で開くと重かったり止まったりするサイズの csv でも捌いてくれます。つよい。

参考

2019/08/20

hub コマンドの user 設定を変更する

hub というコマンドがあります。
GitHub に関連したコマンドが追加された git の wrapper です。
例えば

$ hub clone neovim/neovim

とすると

$ git clone git@github.com:neovim/neovim.git

相当の事をしてくれます。

git の wrapper になってるので、 hub だけで全てを済ませる派の人がいるかもしれません。

環境

OS: macOS Mojave 10.14.6
Homebrew: 2.1.10
Homebrew/homebrew-core: (git revision ea34; last commit 2019-08-20)
hub: version 2.12.3
git: version 2.23.0

設定を変更するきっかけ

$ hub browse tmux/tmux

とすると tmux/tmux をブラウザで開いてくれます。

$ hub browse hoge

とすると atton-/hoge が開かれました。
私の GitHub Account は 'atton-' で取得して 'atton' に変更した経緯があります。
なのでどこかに古い設定が残っている筈。

$ git config --list

で git の設定を確認しても 'atton-' は存在しない。
むしろ github.user=atton になってるくらい。
hub が git の wrapper になってる事のデメリットがちょっとあって

$ hub config --list

としても git config --list の時と同じ内容が出てくる。
つまり hub 経由で config を update しても git の config が変更されそう。

ということで 'atton-' を設定している部分を探してみる。

設定箇所探し + 設定

$ hub --help

hub と git の help が出る
hub 部分に config とか setting とかの項目は無い

$ man hub

config で search するとありました。
どうやら $HOME/.config/hub に書かれているようです。
編集すると 'user: atton-' になっていたので 'user: atton' に修正。

$ hub browse dot_files

とかすると私の dot_files が開かれるようになりました。良し良し。

おまけ

ちなみに私が良く使うコマンドは

$ hub browse

です。

current directory の repository の github ページがブラウザで開きます。

あとは hub clone くらい……?

実際 hub をあまり使わないのは

hub が無い環境で作業することもある
wrapper が隠してくれているオプションとかに「気付かずに助けられている」のは勘弁

とかの理由があります。

なので、個人的にはなるべく git を使うようにしています。

もちろん hub の方が便利な時は hub を使います。

2018/05/20

Homebrew の auto-update を止める

いつからか、Homebrew が upgrade や install の際に auto update をするようになりました。
しかし毎回 update が走るのは煩わしい。
特に連続で何かを install する時などは「さっきも update したじゃん」となります。
なので auto-update を止めました。

環境

macOS Sierra: 10.12.6
Homebrew 1.6.1-7-g6233b9d
Homebrew/homebrew-core (git revision 9623af; last commit 2018-04-16)
zsh: 5.5 (x86_64-apple-darwin16.7.0)

HOMEBREW_NO_AUTO_UPDATE を set

とはいえやることは環境変数を追加するだけです。

export HOMEBREW_NO_AUTO_UPDATE=1

あたりを .zshrc に追記。

これで煩わしい auto-update を無効にできます。

あと、 man brew を読むといろいろと環境変数に指定できることが分かります。が、今はこれだけで良いかな。

参考

2017/11/12

tmux 2.6 を全角記号対応させる

2017/08/30 に tmux 2.6 がリリースされました。
それに伴ない、例によって分割線を ascii にするバージョンをリリースしました。
分割線の表示が変になる問題は Terminal.app が原因だったので、細々と自分用のをリリースしていこうかと(2.5の時)。

なお、作業としては rebase のみでパッチの変更点はありません。

環境

OS: macOS 10.12.6
tmux: border-ascii-2.6(65784831fcf0040b78d68b180c6ca8c1210e4317) (patched)
utf8proc: 2.1(562edab805b82d66622914d06a5da3f53cd54a17)
Homebrew: 1.3.6-217-g441c212
Homebrew/homebrew-core: git revision cf537; last commit 2017-11-11
Ricty: 3.2.2(no option)

インストール用コマンド

$ brew tap atton/customs
$ brew install atton/customs/utf8proc
$ brew install --HEAD atton/customs/tmux

2017/06/02

tmux 2.5 を全角記号対応させる

2017/05/13 に tmux 2.5 が Release されていたので、2.3を全角記号対応させた時のパッチを 2.5 にも当てました。
tmux 2.5 の border-ascii + EastAsianAmbiguous を強制2幅版です。

作業としては rebase のみでパッチそのものの変更点はありません。

環境

macOS Sierra 10.12.5
Homebrew 1.2.1-143-gdaa67886
Homebrew/homebrew-core (git revision cce65; last commit 2017-06-02)
tmux 2.5 (hash だと ae2c5ad76852d6d2e2463e45b13fc8c15b66e4b7 )
utf8proc 2.1
フォントは Ricty

インストール手順

$ brew tap atton-/customs
$ brew install atton-/customs/utf8proc
$ brew install --HEAD atton-/customs/tmux

過去のバージョンが利用したい方は /usr/local/Homebrew/Library/Taps/atton-/homebrew-customs
などにある atton-/customs/tmux の git repository から古いバージョンを checkout してください。

他にも昔のバージョンを参照する方法はあると思いますがちょっと把握していません。

2017/04/22

tmux 2.4 を全角記号対応させる

2017/04/20 に tmux 2.4 が Release されていたので、前回の記事に書いたパッチを 2.4 にも当ててみました。
tmux 2.4 の border-ascii + EastAsianAmbiguous を強制2幅版です。

作業としてはは rebase したただけなので修正点は全くありません。

環境

macOS Sierra 10.12.4
Homebrew 1.1.12-40-g02f018933
Homebrew/homebrew-core (git revision 5559; last commit 2017-04-15)
tmux 2.4 (正確には 2.4リリース以降の fd13731049148d0205fa6ed1843041dad0573677)
utf8proc 2.1
フォントは Ricty

インストール手順

$ brew tap atton-/customs
$ brew install atton-/customs/utf8proc
$ brew install --HEAD atton-/customs/tmux

atton-/customs/tmux の formula は HEAD build しか対応していないので、もし 2.3 のパッチ版が使いたい場合は tap したリポジトリを巻き戻すことで 2.3 が使えるはずです。

おそらくもっと楽な巻き戻し方があると思いますが、個人的には最新しか使っていないので調べていません。

2017/04/16

tmux 2.3 を全角記号対応させる

tmux 2.3 をちょっといじって全角記号の幅を2にした版を作ってみました。

環境

macOS Sierra 10.12.4
Homebrew 1.1.12-40-g02f018933
Homebrew/homebrew-core (git revision 5559; last commit 2017-04-15)
tmux 2.3 (正確には 2.3リリース以降の 640666fb36d7465b188f9d0bedc83ad60b83a1d7)
utf8proc 2.1
フォントは Ricty

状況

tmux を使っていると ─(U+2500) や▽(U+25bd) な文字の幅が半角扱いになってしまい、表示がおかしくなる時があります。

例えば、画面を縦2つに分割すると

のように線が何故か二本表示されたり、記号の表示が変になってしまいます。

これは分割に使用されている文字(─)の幅の扱いを tmux が勘違いしているために起こる問題です。

─ といった記号は EastAsianAmbiguous といった種類に区分され、言語圏によって文字幅が違います。

例えば英語圏では基本的に使う文字幅は1なので ─ の幅は1ですが、日本語圏では全角が基本なので文字幅は2となります。

この問題に関しては https://github.com/hamano/locale-eaw などが詳しいです。

解決法

これは Terminal の設定と locale の設定とフォントに依存するので解決方法はいくつかあります。

今回は

Terminal は EastAsianAmbigous を Full-Width にしている
フォントは日本語フォント( EastAsianAmbiguous は幅2)
locale には依存しない (en_US.UTF-8 でも ja_JP.UTF-8 でもOK)

の時を想定しています。

具体的には tmux が文字幅の取得に使っている utf8proc をちょっといじって、EastAsianAmbiguous の幅を強制的に2にしています。

あと、画面分割に使う文字を ascii にしています。

インストール方法

formula にしてあるので

$ brew tap atton-/customs
$ brew install atton-/customs/utf8proc
$ brew install --HEAD atton-/customs/tmux

でインストールできます。
縦に分割した時に

のようにきちんと線が1本になるはずです。

まとめ

強制的に EastAsianAmbiguous の幅を2にして日本語フォントとの相性を良くしました。

実はこれは対処療法的な解決案で、根本的な解決ではありません。

その辺りは結構長くなると思うので書くなら別の記事で書きます。

参考文献

2016/11/29

Homebrew で Agda 2.5.1.2 を入れる

いつの間にか Homebrew で直接 Agda をインストールできるようになっていたので入れてみたログ。

環境

Mac OSX Yosemte 10.10.5
Homebrew 1.1.2
Homebrew/homebrew-core (git revision a06e; last commit 2016-11-29)
GNU Emacs 25.1.1
Agda 2.5.1.2

Agda のインストール

Homebrew が直接 formula を提供しているので

$ brew install agda

だけでOK。便利。

Agda の設定

$ agda-mode setup

するか、その時に表示される

(load-file (let ((coding-system-for-read 'utf-8))
(shell-command-to-string "agda-mode locate")))

を ~/.emacs や ~/.emacs.d/init.el なりに書いておくとOK。

なんと便利なことに bottle の agda には std-lib が同梱されているので、いきなり open import Relation.Binary.PropositionalEquality とか書いて使うことができます。

特殊文字(Unicode の East Asian Ambiguous) の設定

素の emacs では agda-mode で利用する特殊文字(∏ など)があると表示が乱れます。

これはいくつかの記号の幅が固定されておらず、国によって幅が定義される文字である East Asian Ambigous 文字がソースに含まれる時に発生する問題です。

日本語フォントは基本的に幅2なのですが、英語では幅1らしい。

設定をしないとEmacsが幅を1で処理するため、表示される日本語フォントの幅と合わずに表示が乱れてしまいます。

これを解決する elisp が hamano/locale-eaw に公開されているようなので使ってみます。

README にあるように eaw.el を ~/.emacs/site-lisp に配置して

(add-to-list 'load-path "~/.emacs.d/site-lisp")
(require 'eaw)
(eaw-fullwidth)

を ~/.emacs なり ~/.emacs.d/init.el に書きます。

そうするとEmacs が特殊文字の幅を2として処理してくれます。

ちなみに Terminal や tmux なども East Asian Ambiguous を幅2に設定するのを忘れないように。

過去に自分で書いた elisp もあるのですが割とその場しのぎで書いていたので、これからは eaw.el を使っていこうかなとか。

参考文献

GitHub - hamano/locale-eaw: East Asian Ambiguous Width問題と絵文字の横幅問題の修正ロケール

2015/12/06

Homebrew で debug symbols を埋め込んだ LLVM の bottle を作る

Homebrew の bottle を使って debug information が埋め込まれた LLVM を配ってみんなで読もう、ということになったのでそのログ。

環境

OSX Yosemite 10.10.5
Homebrew 0.9.5
LLVM 3.8
あと自分のマシンじゃないのでチェックしてないけれど El Capitan (10.11.1?)

Release Build の LLVM の bottle 化

私が所属している研究室では Continuation Based C (CbC) という言語を開発していて、LLVM implemented 版があるのでまずはそいつで bottle で作れないかをチェック。

formula は github の ie-developers/ie/cbc にあります。

普通に build した LLVM を bottle にするのは結構簡単で、

brew install --build-bottle ie-developers/ie/cbc
brew bottle cbc

とか。これで build された binary を固めたやつが current directory にできます。

ついでにこうやって書いてね、って出力が sha256 と共に出てくるのでそいつを formula に追記して、 bottle を公開用サーバか何かに置けばOK.

LLVM 3.8 の build を bottle 化

いつからか LLVM は build を repository の top でやると怒るようになってます。

具体的には ./configure をすると怒ってくる。

そいつを回避するために Homebrew 公式の llvm は mktemp を使っているようです。

なので mktemp を使ってやれば最近の LLVM も bottle 化することができます。

LLVM 3.8 を debug information 付きで build して bottle 化

ひとまず LLVM 3.8 を debug information 付きで build する手順としては

git clone http://llvm.org/git/llvm
mkdir llvm_build
cd llvm_build
../llvm/configure --enable-debug-runtime --enable-debug-symbols --disable-optimized --enable-assertions
make -j 3

とか。

Debug+Assets って directory に bin と lib ができるのでそいつで追えます。

具体的には

lldb Debug+Assets/bin/clang

とかできます。

LLVM 3.8 を debug information 付きで build

Homebrew は build する時のディレクトリは build 時に生成して install 後に捨ててしまうっぽいです。

なので build 場所を変えてバイナリを残すように。

formula の prefix ってメソッドがインストール先のディレクトリを返してくれるので、その下で build しちゃいます。(ちなみに prefix の値は "/usr/local/Cellar/llvm_original/llvm3.8/" とか。)

インストール先のディレクトリで直接 build するれば、Debug+Assets が bottle に入るんじゃないかって魂胆。

あと、 Homebrew は make する時に CFLAGS とかを変更しちゃう superenv ってのがあるらしく、そいつは勝手に -g とかを落とすっぽいです。

なので build する時に --env=std とかすると良いらしい。

ってなわけで

brew install --env=std --build-bottle ie-developers/ie/llvm_original
brew bottle

とかすると OK。

ちなみに圧縮前は8.9Gで圧縮後は2.1Gほど。

あと LLVM はとりあえず make するとこで止めてます。ファイル多くなっちゃいますし。

bottle を展開して lldb で追う

あとは落として追えば良いです。

が、 brew が build 時に buildpath を /private/tmp に作っちゃうのでそのパスを解決してやれば良い。

hg clone http://firefly.cr.ie.u-ryukyu.ac.jp/hg/CbC/LLVM_original /Library/Caches/Homebrew/llvm_original--hg
ln -s /Library/Caches/Homebrew/llvm_original--hg/ /private/tmp/llvm_original20151205-42569-opu2br

とか。

これで

lldb /usr/local/Cellar/llvm_original/llvm3.8/build/Debug+Asserts/bin/clang
l main

とかしてソースが表示されます。やったね。

ちなみにこの path は Yosemite の場合なので El Capitan の path はまた別です。

lldb が l main して時にファイルが無いって文句言うはずなのでそれを解決できように symlink 貼れば良いはず。

よもやまばなし

以下適当に本筋と関係無い話。

Cmake で build

Brew 公式の lldb は cmake で make してるっぽいです。

formula の中では std_cmake_args ってものを持ってるらしく、そいつが -DCMAKE_BUILD_TYPES=Release を突っこむっぽいです。

なので CMAKE_BUILD_TYPES=Debug とか入れても弾かれる。

RelWithDebugInfo とかもあるのでそいつでもいけるかも?

superenv を見つけた話

どうも -g が有効じゃないっぽいのでログを漁ってたら

superenv removed: -g -Wcast-qual -m64 -Wall -W -Wwrite-strings

とかあったので調べてみました。ログつよい。

ちなみにログの場所は

less ~/Library/Logs/Homebrew/llvm_original/02.make.cc

とかです。

superenv は -g を落として -O2 とかを入れてくれるっぽいので brew は Debug Build は基本入れない方針っぽいです。

もちろん --env=std で回避手段があるのは流石ですが。

Mach-O

ちなみに -g が効かないのを探すために Mach-O の仕様とか dSYM とか DWARF とか symbols コマンドとか dsymutil とか調べたりしてました。

その辺の hello.c とかコンパイルすると dSYM が作られて、そいつを消すと追えなかったのでこの辺が問題なのかなー、とか思ってゴニョゴニョしてました。

結果的にはハズレか。

make install してない

どうせ Debug+Assets が残ってないと追えないので make install はしてません。

なので brew link とかは効かないです。

make install した clang も Debug+Assets の debug symbols を見にいくはずなので、二重に clang 作るのは容量的に勿体ないかな、と。

参考文献とか

2015/04/21

32bit 版 xv6 を Yosemite で動かす

諸処あって xv6 を Mac で動かしたのでそのログとかをつらつらと。
元々は Vagrant 経由で Virtual Box の VM に構築しようかと思っていたんだけれど、 nested VM できないっぽいので Mac で qemu 動かしました。

環境

Mac OS X Yosemite 10.10.3
Homebrew 0.9.5

必要なもののインストール

brew install homebrew/versions/gcc49

クロスコンパイラが必要なのでそのビルドに必要な gcc-4.9 を入れる

brew install qemu

qemu で xv6 を動かすので必要。

brew tap altkatz/gcc_cross_compilers

i386 とかをターゲットにした gcc の formula があるっぽいのでそれを使う。
元々は jinmel/gcc_cross_compilers に用意されていて、i386 の build だけ直した fork が altkatz/gcc_cross_compilers だったりするみたい。 fork が大量にある。

brew install --with-all-targets gdb

xv6 が .gdbinit を自動で吐くので gdb で debug するのが入れる。
--with-all-targets を付けないと i386 とかの symbol が読めない。

brew install i386-elf-gcc i386-elf-binutils

i386 な elf をサポートした gcc と binutils。
各コマンドの prefix に i386-elf- って付く。

インストールしたものの各バージョンメモ

gcc 4.9.2
qemu 2.2.1
gdb 7.9
i386-elf-gcc 4.9.2
i386-elf-binutils 2.23

xv6 の起動

xv6 を落としてくる。

git clone git://pdos.csail.mit.edu/xv6/xv6.git

Makefile をちょっと書きかえて

TOOLPREFIX = i386-elf-QEMU = qemu-system-i386

にする。

コマンドとかは

make qemu

xv6 が起動する。
ls とかできる。

make qemu-gdb

xv6 が gdb で debug できる状態で起動する。
同じディレクトリで gdb って打つだけで attach する。
どうやら .gdbinit を勝手に吐いてくれてるっぽい。便利。

っぽいです。

参考文献

2014/07/29

Agda を HEAD から build する

brew で gcc と ghc の version を上げたら Agda が build できなくなったので repository から build したおはなし

環境

Mac OSX 10.9.4
Homebrew 0.9.5 (bd3217ea598e9ccf85bb5b1f5ac244f1641378f8)
gcc 4.9.1
ghc 7.6.3 (brew 的には 7.6.3_3)
cabal-install 1.20.0.2 (installed by homebrew)
cabal-install 1.20.0.3 (installed by cabal-install)

経緯

一旦 cabal を消して gcc と ghc の version を上げる

brew uninstall haskell-platform
brew upgrade gcc
brew upgrade ghc
rm -rf ~/.cabal ~/.ghc
brew install haskell-platform

そして cabal で agda を入れる

rehash
cabal update
cabal install cabal-install
rehash
cabal install agda

と、こんなエラーが。

src/full/Agda/Utils/Cluster.hs:50:10:
    Duplicate instance declarations:
      instance Monad m => Functor (EquivT s x y m)
        -- Defined at src/full/Agda/Utils/Cluster.hs:50:10
      instance Functor m => Functor (EquivT s c v m)
        -- Defined in ‘Data.Equivalence.Monad’
cabal: Error: some packages failed to install:
Agda-2.4.0.1 failed during the building phase. The exception was:
ExitFailure 1

調べてみると依存パッケージの equivalence に 0.2.4 から Agda と重複する内容が入ったらしいです。

解決方法としては equivalence を downgrade するか Agda の該当部分を排除しろ、とのこと。

HEAD からの build と haskell-platform からの脱却

stack over flow に書かれてるっぽいのでおそらく HEAD では修正されてないかなー、ということで repository を落としてみる。

cabal info agda

の Source Repo に github があったのでそれを clone。

あと brew 側で haskell-platform ではなく cabal-install を使ってみたり。

何故か依存が自動インストールされなくて happy と alex を入れたりもした。

結果的に実行したコマンドは以下な流れ。

cabal install happy
cabal install alex
git clone https://github.com/agda/agda.git
cd agda
./configure
make

make すると cabal install が走ってくれるみたいで結果的に実行ファイルがきちんと .cabal に入ってた。

ちなみに記事を書いた時点での HEAD は a11a5fb9fc8421747f50d0280c3afe650acd4f1b で Agda の versioning は 2.4.1 扱いになってました。

brew で gcc の install から実行するとなると

brew install gcc
brew install ghc
brew install cabal-install
rehash
cabal update
cabal install cabal-install
rehash
cabal install happy
cabal install alex
git clone https://github.com/agda/agda.git
cd agda
./configure
make

ってな感じでしょうか。

とりあえず Agda 2.4.1 がリリースされれば問題無く build できるはずなので、それまでの間で発生しちゃう問題っぽさそうです。

2014/05/12

rbenv と readline でゴニョゴニョした話

Ruby 2.1.1 を rbenv で入れようとするとビルドがコケる。

brew な readline が 6.3.3 にいつの間にか上がってて、それだとマズいらしい。

6.2.4 とかだと大丈夫らしいので、一旦 checkout してインストールして brew switch とか。

$ brew versions readline
$ pushd /usrl/local
$ git checkout 0181c8a Library/Formula/readline.rb
$ brew install readline
$ brew switch readline 6.2.4
$ git checkout master
$ RUBY_CONFIGURE_OPTS="--enable-shared" rbenv install 2.1.1

そうすれば2.1.1が入りました。

と思ったら brew 側の readline が 6.3.5 に上がってた。
のと、Rubyも2.1.2 が出てた。
ということで試してみる

$ brew install readline
$ brew switch readline 6.3.5
$ RUBY_CONFIGURE_OPTS="--enable-shared" rbenv install 2.1.1
$ RUBY_CONFIGURE_OPTS="--enable-shared" rbenv install 2.1.2

なんか素直に2.1.1も2.1.2も入った。
brew な readline 入ってるとその辺気にしないといけなさそうなのかな。

とりあえず 6.3.5 だと何ら問題は無いらしい。

2014/04/27

gcc-4.8 な感じで Agda を入れる

brew で haskell-platform を入れて、その cabal 経由で Agda を入れてたんですが、いつかの update で apple-gcc42 が formula から消えてしまった様子。

ghc は apple-gcc42 に依存してたみたいだけれど、いつの間にか依存が

mpfr libmpc isl cloog gcc

になってる。

なので apple-gcc42 を消して gcc とかを入れる。

ghcを入れて、 haskell-platform を入れようとすると怒られる。
解決法は

https://github.com/Homebrew/homebrew/issues/28654

らしい。

ってなわけで

$ brew install ghc
$ brew install haskell-platform --cc=/usr/local/bin/gcc-4.8

とかで haskell-platform が入りました。

あとは PATH に $HOME/.cabal を追加して

$ cabal update
$ cabal install cabal-install
$ cabal install agda

とかすれば素直に Agda まで入りました。

2013/02/25

2.0.0 の rubyinterp 対応な最新の Vim を Homebrew でビルドする

ruby 2.0.0-p0 が出たので

atton.blog: rbenv で --enable-shared な ruby 2.0.0-p0 をビルドする

で dylib がある ruby 2.0.0-p0 を rbenv でビルドしてみた。

それを反映した Vim をビルドしてみる。

環境

Mac OSX Mountain Lion
Homebrew 0.9.4
rbenv 0.4.0
ruby-build 20130224
Vim (HEAD は 7.3.831 )

方法

$ brew install --HEAD vim

おしまい。
--enable-shared な ruby があれば一発みたい。
1.9.1 系列から 2.0 への変更にも対応できるような rubyinterp だったらしい。良いですね。

一応

:ruby puts RUBY_VERSION

で

2.0.0

が出る。

なんだか --enable-shared な 2.0.0 に比べてあっさり。
いや、苦労しないのは良いことなので良いか。

2013/02/23

brew な git で zsh の補完が効かなくなった

brew で入れた git を使っていて

$ git add hoge<tab>

とかすると

(anon):6: command not found: __git_main

とかエラーが出て補完できないなど。

こちらを見るとどうやら補完用のスクリプトがちゃんとリンク貼られているかが問題な様子。

$ brew unlink git
$ brew link git

でリンクを貼りなおすと復活。
ログは残ってないけれど、 unlink が 214 で link が215 くらいなので一個消えてたっぽい。
brew cleanup で prune されたのが1つあったよーな気もしたので、それで消えたのかな。

2013/02/19

ruby 1.9.3 の rubyinterp を有効にした最新の Vim を brew でビルドする

rbenv + brew な環境で、rubyを入れて HEAD のVimをビルドしていると

:ruby puts RUBY_VERSION

するとSEGVでVimが落ちてしまう現象が発生。
Mac標準の /usr/bin/vim だと落ちないのでどうやら自分でビルドしたのが問題みたい。
原因がbrewなのかrbenvなのかruby-buildなのかrubyなのかVimなのか分からなかったけれど一応解決したので。

環境

OS X Mountain Lion
XCode 4.6.2
Homebrew 0.9.4
gcc 4.7.2
rbenv 0.4.0
ruby-build 20130208
Vim 7.3.822
ruby 1.9.3-p385

こちらの記事を見ると、どうやら ruby のdylibが無いのが問題の様子。
rbenv global の ruby を見ると確かに無い。

$ ls ~/.rbenv/versions/1.9.3-p374/lib/
libruby-static.a
libyaml-0.2.dylib
libyaml.a
libyaml.dylib
libyaml.la
pkgconfig
ruby

ruby をビルドする時にオプションを指定すると良いらしく、渡し方はこうらしい。
今回は --enable-shared のみを有効化してみる。

なので

$ env CONFIGURE_OPTS="--enable-shared" rbenv install 1.9.3-p385

したけれどmakeに失敗。どうやら cc が問題らしい。

XCode 4.6 の Command Line Tools の gcc 4.2.1 じゃ make できない様子。
brew を使って gcc 4.7.2 を gcc-4.7 という名前で入れていたのでそっちを使ってみる。
Web 見てると env があるのと無いのがあるので消している方でも試す。

$ CC="gcc-4.7" CONFIGURE_OPTS="--enable-shared" rbenv install 1.9.3-p385

これだと通った。

ライブラリを見るとちゃんとdylibがある。

$ ls ~/.rbenv/versions/1.9.3-p385/lib/
libruby.1.9.1-static.a
libruby.1.9.1.dylib
libruby.1.9.dylib
libruby.dylib
libyaml-0.2.dylib
libyaml.a
libyaml.dylib
libyaml.la
pkgconfig
ruby

そっちを使うようにしてから

$ rbenv global 1.9.3-p385

最新のVimをbrewでビルド。ちゃんと通った。

$ brew install --HEAD vim

そして確認

:ruby puts RUBY_VERSION
#=> 1.9.3

動いてる。やたー。

今のところオムニ補完とかで文句も出ていない。
CONFIGURE_OPTS を自分で指定した ruby は始めて使うけれど、大丈夫かなー。
Vim の rubyinterp が 1.9系に対応してるのかとかも気になるけれど、とりあえずビルドできたのでこれで良いかな、とか。

ちなみに最初のlsが 1.9.3-p374 なのは p385 のlsを取る前にp385を消してしまって、ブログのログ用にp374で代替したからだったり。
一応p385の時点でもdylibは無かったです。

登録: 投稿 (Atom)