Moai+Easter Advanced Manual

はじめに

目次

• なぜソースコードからコンパイルするのか？
• ソースコードの入手方法
• イントロダクション
• Windows版をコンパイルする(MinGWを使用)
• Windows版をコンパイルする(VCを使用)
• Windows版をコンパイルする(Cygwinを使用)
• Windows版をコンパイルする(MSYSを使用)
• Windows版をコンパイルする(BCC55(BorlandC Ver5.5.1)またはDMC(Ver8.57)を使用)
• Linux版をコンパイルする
• Linux版をコンパイルする(llvm_clangを使用)
• Linux版をコンパイルする(musl cライブラリを使用)
• Alpine Linux版をコンパイルする
• BSD版をコンパイルする(FreeBSD/NetBSD/DragonFly/OpenBSD)
• Android版をコンパイルする
• Android APK版を作成する
• Android実機へ転送する
• MacOSX(Darwin)版をコンパイルする(darwin8/darwin17)
• MacOSX(Darwin)版をクロスコンパイルする(darwin17)
• 付属ライブラリlibresslについて

なぜソースコードからコンパイルするのか？

• ソースコードが公開されている事実だけでよしとして、それ以上は気にしないという考え方
  
  割とこのような方が多いかもしれません。 この記事の筆者もこのタイプです。
  
  ソースコードが公開されている時点で、世界中の人間が全てをチェック可能な状況に置かれているということです。 仮に大きな問題があった場合、誰か（詳しい人）がソースコードのどの箇所が問題かをピンポイントで指摘することも一応期待できます。 また逆にそのような報告が挙がっていない場合、それを安全性の担保とみなすこともできます。


• ソースコードの内容を一応検査してから使う
  
  あなたにプログラミングに詳しい知り合いがいるなら、このソースコードをざっくりとチェックしてもらうことも可能もしれません。 そんな知り合いはいない方は、プログラミングを扱う掲示板などでこのツールのソースコードのありか(GithubのURL)を記すと何か反応があるかもしれません。 そしてこのツールのソースコードについての意見を聞き、あなたなりの納得を得ることができるかもしれません。


• 付属するソースコードを自らがコンパイルしてそれを使用する
  
  現在我々がgithubにおいて配布している実行バイナリは、このソースコードからコンパイルしたものに他なりません。 ですが例えばあなたがそのことを疑って、本当にそうであるという確証が欲しいと思ったとします。 そのためには、あなた自らがソースコードをコンパイルし、出来上がった実行バイナリを使ってもらうしかありません。

ソースコードの入手方法

"C:\Program Files\7-Zip\7z.exe" x gradle-5.6.4-bin.zip

unzip gradle-5.6.4-bin.zip

7z x gradle-5.6.4-bin.zip

sudo pacman -S p7zip

イントロダクション

基本知識

• Cコンパイラ

C言語で書かれたソースコードをオブジェクトファイル（object file）に変換します。 ここで言うオブジェクトファイルとは、最終的な実行バイナリ（アプリ）になる前の中間形態のファイルであり、 通常その拡張子は「.o」ないしは「.obj」となります。


このオブジェクトファイルもまたテキストファイルではなくバイナリファイルとなるため、人間が中身を読むのは困難です。 尚、プログラミングの経験がある方は「オブジェクト指向」という言葉を聞いたことがあるかもしれませんが、 あれは「オブジェクトファイル」とは関係ありません。


• C++コンパイラ

C++言語で書かれたソースコードをオブジェクトファイルに変換します。 ただし znk_project においてはこれは基本的に使われていません。


• リンカ

リンカはオブジェクトファイルを寄せ集めて一つのファイルに結合（link）させます。 これこそが最終的に作りたい実行バイナリに他なりません。

ただしプロジェクトによってはオブジェクトファイルの数が大量に存在することがあります。 それらを一々個別に指定しては大変ですので、 通常それらを一つに束ねたライブラリ（library）と呼ばれるファイルを作成する方が管理上楽です。 よってリンカが実行バイナリを作る場合、正確にはオブジェクトファイルの他、 いくつかのライブラリを集めて実行バイナリを作ることになります。

ライブラリには大きく分けて動的ライブラリ（dynamic library）と 静的ライブラリ（static library）の二通りがあります。 これら二つの違いですが、とりあえず動的ライブラリは最終的な実行バイナリとは別のファイルとしてインストールし、 静的ライブラリは最終的な実行バイナリと（一つのファイルに）一体化させてインストールするものです （本当はまだまだ重要な違いが色々ありますが、まずはこの認識でよいと思います）。 どちらの方法も一長一短あるため、場合によって使い分けます。


Windowsを使用している方は拡張子がdllというファイルを多分見たことがあるでしょう。 あれが動的ライブラリとなります。 尚、Linux/BSD/Androidの場合は拡張子がso、 Darwinの場合はdylibとなります。

動的ライブラリそのものもまたリンカを使って作成します。 一方、静的ライブラリはリンカではなく、 次に述べるライブラリアンを使って作成します。


• ライブラリアン

オブジェクトファイルを寄せ集めて静的ライブラリを作成します。


プログラマ以外の方は静的ライブラリをご覧になる機会は多分あまりないと思います。 拡張子はOSというよりもコンパイラの種類に依存します。 例えば同じWindowsでもVCならば拡張子は lib、MinGW(gcc)ならば拡張子は a となります。 その他、Linux/BSD/Android/Darwinの場合も拡張子は a です。


• ビルドスクリプト

ビルドスクリプトは、上記のコンパイラ、リンカ、ライブラリアン、その他諸々のコマンド群を、 そのプロジェクトの開発者が定義した規則で実行します。

これがなくても上記のコマンド群はやろうと思えば単独で実行可能ですから、 このようなスクリプトは必須ではありません。 しかし、そのような単独実行を毎回手動でやっていては大変な手間となります。 よってこのビルドスクリプトは事実上の準必須項目と考えてよいでしょう。

ビルドスクリプトには様々な種類がありますが、 znk_project では Makefile を使用します。 一般に make と呼ばれるコマンドを実行することによって、この Makefile に書かれた規則が実行されることになります。

ただしこの make コマンドにはいくつか種類があり、 不幸なことにそれらの make コマンドには互換性がなく、 つまりそれぞれの make コマンドに対応した Makefile を別個に用意しなければなりません。

make コマンドはコンパイラに付属するものを使うこともできますし、別途好きなものをインストールして使うこともできます。 とはいえ、ある程度どの環境ではどの make ファイルを使うものと方針を決めておかないと収拾が付きませんので、 znk_project では次のようにします。


• VC : VC付属のnmakeコマンドを使うものとする
• FreeBSD/NetBSD/DragonFly : 標準インストールされているBSD makeコマンドを使うものとする
• それ以外 : GNU makeコマンドを使うものとする

Windows版をコンパイルしてみたい方へ

Linux版をコンパイルしてみたい方へ

BSD版をコンパイルしてみたい方へ

Android版をコンパイルしてみたい方へ

MacOSX(Darwin)版をコンパイルしてみたい方へ

Windows版をコンパイルする(MinGWを使用)

はじめに

• MinGW32.org

旧来からあるオリジナルのMinGWです。 32bit実行バイナリを作るためのコンパイラ環境です。 この実行バイナリは（32bit/64bit版Windowsを含め）基本的にすべてのWindowsで動作します。


• MinGW64-32

MinGW64が提供するコンパイラのうち、32bit実行バイナリを作るためのコンパイラ環境です。 ただしこれが動作するのは32bit版Windowsの場合は、基本的にはWindows2000 SP4以降に限られます。 64bit版Windowsの場合は、基本的にはどのWindowsでも動作するはずです。


仮にMinGW64-32で作った32bit実行バイナリをWindows98の環境に持っていって起動させると、 例えば「localtime64関数が存在しない」といった旨のエラーが表示されて実行バイナリの起動に失敗します。 そのため、Windows98でも確実に起動可能にするためには、通常MinGW32.orgが必要となります。

これはWindows98のmsvcrt.dllではlocaltime64関数が提供されないためです。 一方、Windows2000 SP4以降でのmsvcrt.dllでは、_localtime64、_gmtime64、_time64、_mktime64 などの64ビット互換シンボルが追加されており、 こちらでは問題ないことになります。

しかし、MinGW64-32のバージョンが新しい場合、新しいWindowsしかサポートしていない可能性もあります （Windowsのバージョンを識別して、MinGW64-32コンパイラ自体が起動できないようになっている場合があります）。 そのため、選択するバージョンには注意する必要があります（この記事ではVer6.4を使います）。


MinGW64のダウンロードサイト（https://sourceforge.net/projects/mingw-w64/）に 「Toolchains targetting Win32」という項目があり、そちらのリンクを辿っていくと 例えば i686-7.1.0-release-win32-sjlj-rt_v5-rev0.7z といった名前のファイルがダウンロードできます。 これがMinGW64-32です。

さらにこれを展開しますと（紛らわしいことに単に） mingw32 という名前のディレクトリが出来上がります （この（MinGW64の）ディレクトリmingw32の総サイズは約485MBほどにもなります。一方MinGW32.orgでは総サイズは200MB程度で済みます）。 またこれに含まれるコンパイラ(gcc)自体は32bit版実行バイナリであり、 このコンパイラを使ってビルドした結果出来上がる実行バイナリ（これをターゲットとも呼びます）も32bit版実行バイナリとなります。


• MinGW64-64

MinGW64が提供するコンパイラのうち、64bit実行バイナリを作るためのコンパイラ環境です。 ただしこれが動作するのは64bit版Windowsに限られます。 64bit版Windowsの場合は、基本的にはどのWindowsでも動作するはずです。

しかし、MinGW64-64のバージョンが新しい場合、新しいWindowsしかサポートしていない可能性もあります （Windowsのバージョンを識別して、MinGW64-64コンパイラ自体が起動できないようになっている場合があります）。 そのため、選択するバージョンには注意する必要があります（この記事ではVer7.1を使います）。


64bit版Windows上では、状況によっては32bit版実行バイナリよりも64bit版実行バイナリの方が実行速度は速くなる場合もあります。 とはいえ、Moaiを含めほとんどのアプリではその実行速度の差は、通常気になるほどのものではありません。 また後者の方がメモリ上で扱えるデータサイズの最大値が大きくなります。 とはいえ、そこまで大規模なデータを扱うことも通常はないでしょう。 その点が気になる方が64bit版実行バイナリを作成することになります。

ただし世の中の流れとして、64bit化が進む傾向がありますので、 手に入る情報量としては64bit版の方が多くなっていると考えられます。 そのため、絶対に64bit版Windowsしか使わないのであれば、 いざトラブルが発生した場合、こちらの方が調査がし易いかもしれません。

必要なコマンド群

MinGW32.orgのインストール

cd C:\mingw32_dir\v6.3\bin
dir

mingw-get install base
mingw-get install g++

MinGW64-32のインストール

cd C:\mingw32_dir\v6.4\dwarf\bin
dir

MinGW32の一般的な使い方によるMoaiのビルド

mingw32-make

'mingw32-make.exe' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。

echo %PATH%

C:\mingw32_dir> echo %PATH%
C:\Windows\system32;C:\Windows;C:\Program Files (x86)\Git\cmd;C:\Program Files\TortoiseSVN\bin

set PATH=C:\mingw32_dir\v6.3\bin;%PATH%

set PATH=C:\mingw32_dir\v6.4\dwarf\bin;%PATH%

C:\mingw32_dir> echo %PATH%
C:\mingw32_dir\v6.3\bin;C:\Windows\system32;C:\Windows;C:\Program Files (x86)\Git\cmd;C:\Program Files\TortoiseSVN\bin

C:\mingw32_dir> echo %PATH%
C:\mingw32_dir\v6.4\dwarf\bin;C:\Windows\system32;C:\Windows;C:\Program Files (x86)\Git\cmd;C:\Program Files\TortoiseSVN\bin

mingw32-make

C:\mingw32_dir> mingw32-make
mingw32-make.exe: *** No targets specified and no makefile found.  Stop.

where mingw32-make

C:\mingw32_dir>where mingw32-make
C:\mingw32_dir\v6.3\bin\mingw32-make.exe

C:\mingw32_dir>where mingw32-make
C:\mingw32_dir\v6.4\dwarf\bin\mingw32-make.exe

mingw32-make --version

C:\mingw32_dir> mingw32-make --version
GNU Make 3.82.90
...

cd C:\znk_project\src

=== DEBUG_MODE=[optimize] MKF_ID=[mingw] MACHINE=[x86]
0. make
1. make install
2. make clean
3. switch debug-mode
4. switch mkfid (using compiler environment)
5. switch machine (target cpu type)
6. mkfgen_update (update your Makefiles using mkfgen)
7. syncronize mkf_triggers in here from mkfsys installed dir
Q. quit

1. 「3. switch debug-mode」を何回か選んでDEBUG_MODEを「optimize」にします。
2. 「4. switch mkfid」を何回か選んでMKF_IDを「mingw」にします。
3. 「5. switch machine」を何回か選んでMACHINEを「x86」にします。
4. 「1. make install」を選びます。 なんらかの理由でこのインストール処理だけを省略し、つまり純粋にコンパイルだけを行いたい場合は、「1. make install」の替わりに「0. make」を選んでください。

mingw32-make -f Makefile_mingw.mak

mingw32-make -f Makefile_mingw.mak install

MinGW32 と auto_trigger によるMoaiのビルドおよびインストール

1. 「3. switch debug-mode」を何回か選んでDEBUG_MODEを「optimize」にします。
2. 「4. switch mkfid」を何回か選んでMKF_IDを「mingw」にします。
3. 「5. switch machine」を何回か選んでMACHINEを「x86」にします。
4. 「1. make install」を選びます。 なんらかの理由でこのインストール処理だけを省略し、つまり純粋にコンパイルだけを行いたい場合は、「1. make install」の替わりに「0. make」を選んでください。

MinGW64-64のインストール

cd C:\mingw64_dir\v7.1\win_seh\bin
dir

MinGW64-64の一般的な使い方によるMoaiのビルド

mingw32-make

set ZNK_MINGW64_DIR=C:\mingw64_dir\v7.1\win_seh
cd znk_project\mkfsys\bat_utils
setenv_mingw.bat

mingw32-make

C:\mingw64_dir> mingw32-make
mingw32-make.exe: *** No targets specified and no makefile found.  Stop.

cd znk_project\src
make_world.bat

=== DEBUG_MODE=[optimize] MKF_ID=[mingw] MACHINE=[x86]
0. make
1. make install
2. make clean
3. switch debug-mode
4. switch mkfid (using compiler environment)
5. switch machine (target cpu type)
6. mkfgen_update (update your Makefiles using mkfgen)
7. syncronize mkf_triggers in here from mkfsys installed dir
Q. quit

1. 「3. switch debug-mode」を何回か選んでDEBUG_MODEを「optimize」にします。
2. 「4. switch mkfid」を何回か選んでMKF_IDを「mingw」にします。
3. 「5. switch machine」を何回か選んでMACHINEを「x64」にします。
4. 「1. make install」を選びます。 なんらかの理由でこのインストール処理だけを省略し、つまり純粋にコンパイルだけを行いたい場合は、「1. make install」の替わりに「0. make」を選んでください。

mingw32-make -f Makefile_mingw.mak

mingw32-make -f Makefile_mingw.mak install

MinGW64-64 と auto_trigger によるMoaiのビルドおよびインストール

1. 「3. switch debug-mode」を何回か選んでDEBUG_MODEを「optimize」にします。
2. 「4. switch mkfid」を何回か選んでMKF_IDを「mingw」にします。
3. 「5. switch machine」を何回か選んでMACHINEを「x64」にします。
4. 「1. make install」を選びます。 なんらかの理由でこのインストール処理だけを省略し、つまり純粋にコンパイルだけを行いたい場合は、「1. make install」の替わりに「0. make」を選んでください。

Windows版をコンパイルする(VCを使用)

必要なコマンド群

Moaiのコンパイルおよびインストール

• ZNK_VC_DIR

VC本体のトップディレクトリの位置になります。
指定する値は、「VC」という名前のディレクトリが現れるまでのパスです（「VC」までは含めて指定します）。 あるいは bin, include, lib が直下に現れるまでのパスを明示的に指定していただいても構いません。 どちらでもよいということです。


「VC」という名前のディレクトリは、VS2003では「Vc7」、VC6.0では「VC98」という名前になっていると思います。 （あまりいないとは思いますが）これらを使っている方は参考にしてください。

またVS2017以降は「VC」ディレクトリの直下にbin, include, libは配置されておらず、 「VC\Tools\MSVC\バージョン番号」といったディレクトリの直下に位置が変更されています。 この場合でも「VC」ディレクトリが現れるまでのパスを指定してもよいですし、 「VC\Tools\MSVC\バージョン番号」までのパスを指定してもよいです。 どちらでも構いません。


• ZNK_VC_WINSDK_DIR

Windows SDKのトップディレクトリの位置になります。
指定する値は、「Program Files (x86)」に相当するディレクトリが現れるまでのパスです。 あるいは bin, include, lib が直下に現れるまでのパスを明示的に指定していただいても構いません。 どちらでもよいということです。


• ZNK_VC_UCRT_DIR

Windows Universal CRT SDKのトップディレクトリの位置になります。
これに関してはVS2015以降をお使いの方が対象になります （Universal CRTとはVS2015以降に新しく導入されたC言語標準ライブラリです）。 また、Windows SDK 10を使っている場合は、通常そのトップディレクトリと同じになるはずです。
指定する値は、「Program Files (x86)」に相当するディレクトリが現れるまでのパスです。 あるいは bin, include, lib が直下に現れるまでのパスを明示的に指定していただいても構いません。 どちらでもよいということです。

REM VC Directory
    set        ZNK_VC_DIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC
REM set        ZNK_VC_DIR=D:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
REM set        ZNK_VC_DIR=C:\MyVC\VC


REM Windows SDK
    set ZNK_VC_WINSDK_DIR=C:\Program Files (x86)
REM set ZNK_VC_WINSDK_DIR=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A
REM set ZNK_VC_WINSDK_DIR=D:\Program Files (x86)
REM set ZNK_VC_WINSDK_DIR=D:\Program Files (x86)\Windows Kits\8.1


REM Windows Universal CRT SDK
    set   ZNK_VC_UCRT_DIR=C:\Program Files (x86)
REM set   ZNK_VC_UCRT_DIR=D:\Program Files (x86)
REM set   ZNK_VC_UCRT_DIR=D:\Program Files (x86)\Windows Kits\10

1. setコマンド

後ろに続く代入により、環境変数を設定してます（=の左側が環境変数名、右側がその値です）。

setの前後に（見なすさなどのために）半角スペースをいくつか置くのは構いません。 ただしその他の箇所には（値そのものにそれが含まれている場合を除き）不要な半角スペースなどを入れてはいけません。


2. 行頭のREM

その行がコメントであることを意味し、その行の記述はまるごと無視されます。 コメントはその箇所の意味をユーザに示すのに（あるいは自分用の備忘録として）利用できます。 また、いくつかの候補がある場合にその他を一時的に無効にするのにも利用できます。

REMの直後に何か文字列を置く場合は、その間に最低ひとつ以上半角スペースを挟む必要があります。

1. 「3. switch debug-mode」を何回か選んでDEBUG_MODEを「optimize」にします。
2. 「4. switch mkfid」を何回か選んでMKF_IDを「vc」にします。
3. 「5. switch machine」を何回か選んでMACHINEを「x86」あるいは「x64」にします。
4. 「1. make install」を選びます。 なんらかの理由でこのインストール処理だけを省略し、つまり純粋にコンパイルだけを行いたい場合は、「1. make install」の替わりに「0. make」を選んでください。

Windows版をコンパイルする(Cygwinを使用)

必要なコマンド群

Moaiのコンパイルおよびインストール

sh ./make_world.sh install

動作確認

Moai : config load OK.
Moai : target load OK.
Moai : analysis load OK.
Moai : Filter Loading [filters/….myf]
Moai : Plugin Loading [plugins/….so]
…
Moai : acceptable_host=[LOOPBACK]
Moai : blocking_mode=[0]
Moai : AutoGet PrivateIP=[192.168.…].
Moai : Listen port 8124...

Moai : ObserveR : 1-th sock events by select.

Windows版をコンパイルする(MSYSを使用)

はじめに

必要なコマンド群

MSYSのインストール

cd C:\msys_dir\v1\bin
dir

mingw-get install msys-base

$ make --version

$ make --version
GNU Make 3.81
...

$ mount

C:\msys_dir\v1\msys\1.0 on /usr   type user (binmode,noumount)
C:\msys_dir\v1\msys\1.0 on /      type user (binmode,noumount)
C:\msys_dir\v1          on /mingw type user (binmode)
C:\Users\Zenkaku\AppData\Local\Temp on /tmp type user (binmode,noumount)
c: on /c type user (binmode,noumount)

c:/msys_dir/v1 /mingw

c:/mingw32_dir /mingw

$ mount /mingw

$ umount /mingw
$ mount /mingw

Moaiのコンパイルおよびインストール

sh ./make_world.sh install

Windows版をコンパイルする(BCC55(BorlandC Ver5.5.1)またはDMC(Ver8.57)を使用)

はじめに

BCC55(Borland C++ Compiler 5.5) における必要なコマンド群

DMC(Digital Mars C/C++) における必要なコマンド群

GNU make(gmake)の単独インストール

• Description「Binaries」のZip
• Description「Dependencies」のZip

• make-3.81-bin.zip の方のbin
make.exe（gmake本体）


• make-3.81-dep.zip の方のbin
libiconv2.dll と libint3.dll（ gmake の起動にあたって必要となる動的ライブラリ）

BCC55でのビルドとインストール

1. BCC55がインストールされているパスを環境変数ZNK_BCC55_DIRに設定する。

この値は %ZNK_BCC55_DIR%\Bin\bcc32.exe が存在するような形で設定しなければならない。

尚、znk_project\mkfalt\bcc55 内にある config_sample.bat を config.bat という名前に変更し、 その中身の以下の行にある ZNK_BCC55_DIR の値を書き変えてもよい。



REM BCC55 install directory
set ZNK_BCC55_DIR=C:\bcc55_dir



2. 環境変数MAKEにgmakeそのもののパスを設定する。

この設定は直前のgmakeのインストールで既に行っていると思うが、念のためここでも繰り返し述べておこう。 例えばgmakeの実体が「C:\gmake_dir\make-3.81-bin\bin\make.exe」である場合、 環境変数 MAKE の値をそのまま「C:\gmake_dir\make-3.81-bin\bin\make.exe」とすればよい。

尚、znk_project\mkfalt\bcc55 内にある config_sample.bat を config.bat という名前に変更し、 その中身の以下の行にある MAKE の値を書き変えてもよい。



REM GNU make
set MAKE=..\gmake_dir\make-3.81-bin\bin\make



3. znk_project\mkfalt\bcc55 内へ移動し、make_world.batを実行する。

これですべてのコンパイルおよびインストールが自動で行われるはずだ。


ただしlibresslについては znk_project/mkfalt/prebuild/ 内のプレビルドdll(libtls-17.dll）を使用する。 これについては我々の環境でVC8.0(VS2005)を使ってビルドしたものである （既に述べた通り、BCC55/DMCでのlibresslのビルドは非常に難しい）。 prebuild.mak という Makefile では、この dll を moai と raraku のインストールディレクトリにコピーする。

環境変数 ZNK_INSTALL_DIR を指定している場合はそこにインストールされる。 特にコンパイルされた実行バイナリやライブラリなどは、%ZNK_INSTALL_DIR%\moai-v$REL_VER\bin\windows-x86 という名前のディレクトリに配置される。 Rarakuの場合も同様で、%ZNK_INSTALL_DIR%\raraku-v$RRK_VER（$RRK_VERはRarakuのバージョン番号で例えば1.0など）という名前のディレクトリ配下にインストールされる。

尚、環境変数 ZNK_INSTALL_DIR が指定されていない場合は、src ディレクトリの一つ上の階層に install_dir というディレクトリが生成され、 その配下に moai-v$REL_VER や raraku-v$RRK_VER などが配置される。


このバッチファイルにより、一つ上の make_list.bat 内に記述されたリストを元に、 すべてのMakefile（拡張子はmak）が順番にmakeされる。 コンパイル時の一時的なオブジェクトファイルなどはすべて znk_project\mkfalt\dmc\out_dir 配下に格納される。
あるライブラリや実行バイナリだけをピンポイントにコンパイルしたい場合は、 以下のようなバッチファイルを作るとよいだろう。


@echo off
call _make.bat easter.mak
pause

上記は easter のみをコンパイルする。

あるいはあるライブラリや実行バイナリだけをピンポイントにインストールしたい場合は、 以下のようなバッチファイルを作るとよいだろう。


@echo off
call _make.bat easter.mak install
pause

上記は easter のみをコンパイルとインストールする。

DMCでのビルドとインストール

1. DMCがインストールされているパスを環境変数ZNK_DMC_DIRに設定する。

この値は %ZNK_DMC_DIR%\Bin\bcc32.exe が存在するような形で設定しなければならない。

尚、znk_project\mkfalt\dmc 内にある config_sample.bat を config.bat という名前に変更し、 その中身の以下の行にある ZNK_DMC_DIR の値を書き変えてもよい。



REM DMC install directory
set ZNK_DMC_DIR=C:\dmc_dir\dmc-master



2. 環境変数MAKEにgmakeそのもののパスを設定する。

この設定は直前のgmakeのインストールで既に行っていると思うが、念のためここでも繰り返し述べておこう。 例えばgmakeの実体が「C:\gmake_dir\make-3.81-bin\bin\make.exe」である場合、 環境変数 MAKE の値をそのまま「C:\gmake_dir\make-3.81-bin\bin\make.exe」とすればよい。

尚、znk_project\mkfalt\dmc 内にある config_sample.bat を config.bat という名前に変更し、 その中身の以下の行にある MAKE の値を書き変えてもよい。



REM GNU make
set MAKE=..\gmake_dir\make-3.81-bin\bin\make



3. znk_project\mkfalt\dmc 内へ移動し、make_world.batを実行する。

これですべてのコンパイルおよびインストールが自動で行われるはずだ。


ただしlibresslについては znk_project/mkfalt/prebuild/ 内のプレビルドdll(libtls-17.dll）を使用する。 これについては我々の環境でVC8.0(VS2005)を使ってビルドしたものである （既に述べた通り、BCC55/DMCでのlibresslのビルドは非常に難しい）。 prebuild.mak という Makefile では、この dll を moai と raraku のインストールディレクトリにコピーする。

環境変数 ZNK_INSTALL_DIR を指定している場合はそこにインストールされる。 特にコンパイルされた実行バイナリやライブラリなどは、%ZNK_INSTALL_DIR%\moai-v$REL_VER\bin\windows-x86 という名前のディレクトリに配置される。 Rarakuの場合も同様で、%ZNK_INSTALL_DIR%\raraku-v$RRK_VER（$RRK_VERはRarakuのバージョン番号で例えば1.0など）という名前のディレクトリ配下にインストールされる。

尚、環境変数 ZNK_INSTALL_DIR が指定されていない場合は、src ディレクトリの一つ上の階層に install_dir というディレクトリが生成され、 その配下に moai-v$REL_VER や raraku-v$RRK_VER などが配置される。


このバッチファイルにより、一つ上の make_list.bat 内に記述されたリストを元に、 すべてのMakefile（拡張子はmak）が順番にmakeされる。 コンパイル時の一時的なオブジェクトファイルなどはすべて znk_project\mkfalt\dmc\out_dir 配下に格納される。
あるライブラリや実行バイナリだけをピンポイントにコンパイルしたい場合は、 以下のようなバッチファイルを作るとよいだろう。


@echo off
call _make.bat easter.mak
pause

上記は easter のみをコンパイルする。

あるいはあるライブラリや実行バイナリだけをピンポイントにインストールしたい場合は、 以下のようなバッチファイルを作るとよいだろう。


@echo off
call _make.bat easter.mak install
pause

上記は easter のみをコンパイルとインストールする。

動作確認

Linux版をコンパイルする

必要なコマンド群

コンパイルおよびインストール

1. ターミナル(xterm, urxvtなど)を開き、インストール先のパスを環境変数 ZNK_INSTALL_DIR で指定します。



export ZNK_INSTALL_DIR=$HOME/install_dir


環境変数 ZNK_INSTALL_DIR で指定されたディレクトリが存在しない場合は自動的に生成されます。 Moaiの場合、$ZNK_INSTALL_DIR/moai-v$REL_VER（$REL_VERはMoaiのバージョン番号で例えば2.3など）という名前のディレクトリが生成され、 必要なファイルがそのディレクトリ配下へとインストールされます。

特にコンパイルされた実行バイナリやライブラリなどは、$ZNK_INSTALL_DIR/moai-v$REL_VER/bin/$PLATFORM という名前のディレクトリに配置されます。 ここで $PLATFORM は実行バイナリの種類を表し、例えばLinuxにおいては、linux-x86、linux-x64 といった文字列になります。 Rarakuの場合も同様で、$ZNK_INSTALL_DIR/raraku-v$RRK_VER（$RRK_VERはRarakuのバージョン番号で例えば1.0など）という名前のディレクトリ配下にインストールされます。

尚、環境変数 ZNK_INSTALL_DIR が指定されていない場合は、src ディレクトリの一つ上の階層に install_dir というディレクトリが生成され、 その配下に moai-v$REL_VER や raraku-v$RRK_VER などが配置されます。


尚、環境変数INST_MACHINEに「x86」または「x64」を明示的に設定して上記を実行した場合は、それぞれ32bit版または64bit版バイナリが生成されます。 この環境変数を指定していない場合は、Makefile_linux.mak 内で uname -m コマンドが実行され、その結果により 32bit版か64bit版かが自動的に決定されます。


2. srcディレクトリへ移動し、以下のシェルスクリプトを実行します。



cd znk_project/src
sh ./make_world.sh install


これですべてのコンパイルおよびインストールが自動で行われます。


このシェルスクリプトにより、Makefile_linux.mak の存在する各ディレクトリへ自動的に移動しつつ make -f Makefile_linux.mak install が実行されます。 コンパイル後の実行バイナリは各ディレクトリ内のout_dirに格納されます。
インストール処理だけを省略したい、つまり純粋にコンパイルだけを行いたい場合は、 各々のディレクトリで直接「make -f Makefile_linux.mak」を実行した方がよいでしょう。 「sh ./make_world.sh」と実行することもできますが、 純粋にコンパイルだけでは必要なライブラリやツールがまだ所定の位置に配置されないため、 それらに依存するツールのコンパイルにおいて、リンクに失敗するかもしれません。

動作確認

cd $ZNK_INSTALL_DIR/moai-v2.3
sh moai.sh

Moai : config load OK.
Moai : target load OK.
Moai : analysis load OK.
Moai : Filter Loading [filters/….myf]
Moai : Plugin Loading [plugins/….so]
…
Moai : acceptable_host=[LOOPBACK]
Moai : blocking_mode=[0]
Moai : AutoGet PrivateIP=[192.168.…].
Moai : Listen port 8124...

Moai : ObserveR : 1-th sock events by select.

cd $ZNK_INSTALL_DIR/moai-v2.3
sh moai.sh -acceptable_any

Linux版をコンパイルする(llvm_clangを使用)

はじめに

必要なコマンド群

コンパイルおよびインストール

1. ターミナル(xterm, urxvtなど)を開き、llvm_clangのインストール先を環境変数 ZNK_LLVM_CLANG_DIR で指定します。

例えば、$HOME/Downloads/llvm_dir/v3.9/install_dir に llvm_clang がインストールされている場合、 以下のように設定します。



export ZNK_LLVM_CLANG_DIR=$HOME/Downloads/llvm_dir/v3.9/install_dir


念のために補足しますが、上記は「$ZNK_LLVM_CLANG_DIR/bin/clang」と入力すると llvm_clang が実行できる状態にしておくということです。 そのように実行し、「clang-3.9: error: not input file」などといったエラーが出れば成功です。


llvm_clang の場合でも使用される Makefile は gcc の場合と同じくMakefile_linux.mak となります。 Makefile_linux.mak は環境変数 ZNK_LLVM_CLANG_DIR が定義されている場合、 llvm_clang を使用したビルドに自動的に切り替えるようになっています。

そのため、この環境変数 ZNK_LLVM_CLANG_DIR の定義は必須です。 たとえ単に「clang」と打ってllvm_clangが実行できるようにPATHを設定していたとしてもです。 例えば llvm_clang が最初からシステムにインストールされている状態（ /usr/bin/clang などが存在する状態）であった場合は、 「export ZNK_LLVM_CLANG_DIR=/usr」と設定することになります。


2. Moaiをインストールする予定のパスを環境変数 ZNK_INSTALL_DIR で指定します。



export ZNK_INSTALL_DIR=$HOME/install_dir


これについての詳細は既に述べた gcc 版でのインストールと同様です。 詳しくはそちらを参照してください。


3. srcディレクトリへ移動し、以下のシェルスクリプトを実行します。



cd znk_project/src
sh ./make_world.sh install


これについての詳細は既に述べた gcc 版でのインストールと同様です。 詳しくはそちらを参照してください。

動作確認

cd $ZNK_INSTALL_DIR/moai-v2.3
sh moai.sh

Linux版をコンパイルする(musl cライブラリを使用)

はじめに

必要なコマンド群

cd $HOME/Downloads
mkdir musl_dir
mv musl-1.2.6.tar.xz musl_dir/
cd musl_dir
tar xvf musl-1.2.6.tar.xz
cd musl-1.2.6

./configure --prefix=../install_dir
make
make install

コンパイルおよびインストール

1. ターミナルより、（znk_project内蔵の）muslをインストールする予定の絶対パスを環境変数 ZNK_MUSL_DIR で指定します。

この場合の「muslのインストール先」とは、znk_project/musl内でビルドしたライブラリやヘッダファイルの格納先ということになります。 これは別にどこでも構いませんが、例えば、$HOME/musl_dir に musl をインストールしたい場合、 以下のように設定します。



export ZNK_MUSL_DIR=$HOME/musl_dir


念のために補足しますが、上記は最終的に「$ZNK_MUSL_DIR/lib/libc.so」などが存在する状態になるということです。

また ZNK_MUSL_DIR に指定する値は必ず絶対パスとしてください。 これはディレクトリを変更した場合でも musl のある位置が狂わないようにするためです。 少しトリッキーですが以下のようにすることで「相対パス」風な指定で絶対パスを指定することもできます。



export ZNK_MUSL_DIR=`pwd`/../install_dir/musl_dir


「`pwd`」の部分が今自分がいるディレクトリの絶対パスとなります。 上記はそこから一つ上のinstall_dirの下のmusl_dirへmuslをインストールするということです。


musl の場合でも使用する Makefile は Makefile_linux.mak となります。 Makefile_linux.mak は環境変数 ZNK_MUSL_DIR が定義されている場合、 musl を使用したビルドに自動的に切り替えるようになっています。
Moaiをすべてビルドし終わった後は、環境変数ZNK_MUSL_DIRで指定した先のmusl（znk_project由来のmusl）は 役目を終えていますので邪魔であれば削除しても構いません。


2. Moaiをインストールする予定のパスを環境変数 ZNK_INSTALL_DIR で指定します。



export ZNK_INSTALL_DIR=$HOME/install_dir


これについての詳細は既に述べた glibc 版でのインストールと同様です。 詳しくはそちらを参照してください。


3. srcディレクトリへ移動し、以下のシェルスクリプトを実行します。



cd znk_project/src
sh ./make_world.sh install


これについての詳細は既に述べた glibc 版でのインストールと同様です。 詳しくはそちらを参照してください。

動作確認

cd $ZNK_INSTALL_DIR/moai-v2.3
sh moai_musl.sh

cd $ZNK_INSTALL_DIR/moai-v2.3
LINUX_SFX=_musl sh moai.sh

llvm_clangとmuslでビルドする

1. ターミナルより、llvm_clangがインストールされているトップディレクトリのパスを環境変数 ZNK_LLVM_CLANG_DIR で指定します。

例えば、$HOME/Downloads/llvm_dir/v3.9/install_dir に llvm_clang がインストールされている場合、 以下のように設定します。



export ZNK_LLVM_CLANG_DIR=$HOME/Downloads/llvm_dir/v3.9/install_dir


念のために補足しますが、上記は「$ZNK_LLVM_CLANG_DIR/bin/clang」と入力すると llvm_clang が実行できる状態にしておくということです。


llvm_clang の場合でも使用される Makefile は gcc の場合と同じくMakefile_linux.mak となります。 Makefile_linux.mak は環境変数 ZNK_LLVM_CLANG_DIR が定義されている場合、 llvm_clang を使用したビルドに自動的に切り替えるようになっています。

そのため、この環境変数 ZNK_LLVM_CLANG_DIR の定義は必須です。 たとえ単に「clang」と打ってllvm_clangが実行できるようにPATHを設定していたとしてもです。 例えば llvm_clang が最初からシステムにインストールされている状態（ /usr/bin/clang などが存在する状態）であった場合は、 「export ZNK_LLVM_CLANG_DIR=/usr」と設定することになります。


2. ターミナルより、（znk_project内蔵の）muslをインストールする予定の絶対パスを環境変数 ZNK_MUSL_DIR で指定します。

この場合の「muslのインストール先」とは、znk_project/musl内でビルドしたライブラリやヘッダファイルの格納先ということになります。 これは別にどこでも構いませんが、例えば、$HOME/musl_dir に musl をインストールしたい場合、 以下のように設定します。



export ZNK_MUSL_DIR=$HOME/musl_dir


念のために補足しますが、上記は最終的に「$ZNK_MUSL_DIR/lib/libc.so」などが存在する状態になるということです。


musl の場合でも使用する Makefile は Makefile_linux.mak となります。 Makefile_linux.mak は環境変数 ZNK_MUSL_DIR が定義されている場合、 musl を使用したビルドに自動的に切り替えるようになっています。


3. Moaiをインストールする予定のパスを環境変数 ZNK_INSTALL_DIR で指定します。



export ZNK_INSTALL_DIR=$HOME/install_dir


これについての詳細は既に述べた glibc 版でのインストールと同様です。 詳しくはそちらを参照してください。


4. srcディレクトリへ移動し、以下のシェルスクリプトを実行します。



cd znk_project/src
sh ./make_world.sh install


これについての詳細は既に述べた glibc 版でのインストールと同様です。 詳しくはそちらを参照してください。

muslで動的リンクを使ったバイナリを作る場合における注意点

#include <stdio.h>
int main( int argc, char** argv )
{
	printf( "hello.\n" );
	return 0;
}

$ZNK_MUSL_DIR/bin/musl-gcc my_app.c -o my_app

./my_app
bash: ./my_app: No such file or directory.

export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH
./my_app
bash: ./my_app: No such file or directory.

/lib64/ld-linux-x86-64.so.2 ./my_app

readelf -l ./my_app

    [Requesting program interpreter: /lib/ld-musl-x86_64.so.1]

ls /lib/ld-musl-x86_64.so.1
ls: cannot access '/lib/ld-musl-x86_64.so.1': No such file or directory

/lib/ld-musl-x86_64.so.1 ./my_app

Notes on Dynamic Linking
------------------------

If dynamic linking is enabled, one file needs to be installed outside
of the installation prefix: /lib/ld-musl-$ARCH.so.1. This is the
dynamic linker. Its pathname is hard-coded into all dynamic-linked
programs, so for the sake of being able to share binaries between
systems, a consistent location should be used everywhere. 

LDSO_PATHNAME = $(syslibdir)/ld-musl-$(ARCH)$(SUBARCH).so.1

...途中省略...

$(DESTDIR)$(LDSO_PATHNAME): $(DESTDIR)$(libdir)/libc.so
	$(INSTALL) -D -l $(libdir)/libc.so $@ || true

$ZNK_MUSL_DIR/lib/libc.so
musl libc (x86_64)
Version 1.2.6
Dynamic Program Loader
Usage: $ZNK_MUSL_DIR/lib/libc.so [options] [--] pathname [args]

/lib/ld-musl-x86_64.so.1 ./my_app

$ZNK_INSTALL_DIR/lib/libc.so ./my_app
hello.

./libc.so ./my_app
hello.

$ZNK_INSTALL_DIR/bin/musl-gcc -c my_app.c
$ZNK_INSTALL_DIR/bin/musl-gcc -o my_app my_app.o -Wl,--dynamic-linker,libc.so

readelf -l ./my_app

    [Requesting program interpreter: libc.so]

./my_app
hello.

cd ..
my_dir/my_app
bash: my_dir/my_app: No such file or directory.

PATH=my_dir:$PATH my_dir/my_app
bash: my_dir/my_app: No such file or directory.

$ZNK_INSTALL_DIR/bin/musl-gcc -c my_app.c
$ZNK_INSTALL_DIR/bin/musl-gcc -o my_app my_app.o -Wl,--dynamic-linker,/lib64/ld-linux-x86-64.so.2

./my_app
./my_app: error while loading shared libraries: /usr/lib/libc.so: invalid ELF header

#!/bin/sh
# For musl dynamic load binary.
# For example, rename this file to your_app, and run libc.so(musl dynamic linker) with your_app.bin(native binary)
# Regarding the problem of "$0" when using source command, there is a way to address it using SELF_PATH="${BASH_SOURCE:-$0}",
# but this environment variable requires bash 3.0 or later.
SELF_PATH="$0"
SELF_NAME=`basename $SELF_PATH`
if test "$THIS_DIR" = "" ; then 
	THIS_DIR=`dirname $SELF_PATH`
fi
BIN_FILE=$THIS_DIR/$SELF_NAME.bin
if test "$DYNAMIC_LINKER" = "" ; then 
	if test "$ZNK_MUSL_DIR" = "" ; then 
		DYNAMIC_LINKER=$THIS_DIR/libc.so
	else
		DYNAMIC_LINKER=$ZNK_MUSL_DIR/lib/libc.so
	fi
fi
$DYNAMIC_LINKER $BIN_FILE "$@"

muslで静的リンクを使ったバイナリを作る場合における注意点

musl-gcc -nostdlib -o my_app my_app.o -static

./my_app
hello.

#include <dlfcn.h>
#include "dynlink.h"

static void *stub_dlopen(const char *file, int mode)
{
	__dl_seterr("Dynamic loading not supported");
	return 0;
}

weak_alias(stub_dlopen, dlopen);

#ifndef FEATURES_H
#define FEATURES_H

#include "../../include/features.h"

#define weak __attribute__((__weak__))
#define hidden __attribute__((__visibility__("hidden")))
#define weak_alias(old, new) \
	extern __typeof(old) new __attribute__((__weak__, __alias__(#old)))

#endif

ALL_OBJS = $(addprefix obj/, $(filter-out $(REPLACED_OBJS), $(sort $(BASE_OBJS) $(ARCH_OBJS))))

LIBC_OBJS = $(filter obj/src/%,$(ALL_OBJS)) $(filter obj/compat/%,$(ALL_OBJS))
LDSO_OBJS = $(filter obj/ldso/%,$(ALL_OBJS:%.o=%.lo))
CRT_OBJS = $(filter obj/crt/%,$(ALL_OBJS))

AOBJS = $(LIBC_OBJS)
LOBJS = $(LIBC_OBJS:.o=.lo)

...途中略...

lib/libc.so: $(LOBJS) $(LDSO_OBJS)
	$(CC) $(CFLAGS_ALL) $(LDFLAGS_ALL) -nostdlib -shared \
	-Wl,-soname,libc.so \
	-Wl,-e,_dlstart -o $@ $(LOBJS) $(LDSO_OBJS) $(LIBCC)

lib/libc.a: $(AOBJS)
	rm -f $@
	$(AR) rc $@ $(AOBJS)
	$(RANLIB) $@

obj/%.o: $(srcdir)/%.c $(GENH) $(IMPH)
$(CC_CMD)

musl-gcc内部で行われていることを完全掌握する

#!/bin/sh
exec "${REALGCC:-gcc}" "$@" -specs "$ZNK_INSTALL_DIR/lib/musl-gcc.specs"

%rename cpp_options old_cpp_options

*cpp_options:
-nostdinc -isystem $incdir -isystem include%s %(old_cpp_options)

*cc1:
%(cc1_cpu) -nostdinc -isystem $incdir -isystem include%s

*link_libgcc:
-L$libdir -L .%s

*libgcc:
libgcc.a%s %:if-exists(libgcc_eh.a%s)

*startfile:
%{!shared: $libdir/Scrt1.o} $libdir/crti.o crtbeginS.o%s

*endfile:
crtendS.o%s $libdir/crtn.o

*link:
-dynamic-linker $ldso -nostdlib %{shared:-shared} %{static:-static} %{rdynamic:-export-dynamic}

*esp_link:


*esp_options:


*esp_cpp_options:

%rename cpp_options old_cpp_options

%rename old_name new_name
	Rename the spec string old_name to new_name. 

*cpp_options:
-nostdinc -isystem $incdir -isystem include%s %(old_cpp_options)

%s
	Current argument is the name of a library or startup file of some sort.
	Search for that file in a standard list of directories and substitute the full name found.
	The current working directory is included in the list of directories scanned.

*cc1:
%(cc1_cpu) -nostdinc -isystem $incdir -isystem include%s

*link_libgcc:
-L$libdir -L .%s

*libgcc:
libgcc.a%s %:if-exists(libgcc_eh.a%s)

*startfile:
%{!shared: $libdir/Scrt1.o} $libdir/crti.o crtbeginS.o%s

*endfile:
crtendS.o%s $libdir/crtn.o

*link:
-dynamic-linker $ldso -nostdlib %{shared:-shared} %{static:-static} %{rdynamic:-export-dynamic}

%:function(args)
	Call the named function function, passing it args.
	args is first processed as a nested spec string, then split into an argument vector in the usual fashion.
	The function returns a string which is processed as if it had appeared literally as part of the current spec.
    The following built-in spec functions are provided:

	if-exists
		The if-exists spec function takes one argument, an absolute pathname to a file.
		If the file exists, if-exists returns the pathname.
		Here is a small example of its usage:

			*startfile:
			crt0%O%s %:if-exists(crti%O%s) crtbegin%O%s

%{S:X}
	Substitutes X, if the `-S' switch was given to GCC. 

Alpine Linux版をコンパイルする

はじめに

必要なコマンド群

apk add build-base

コンパイルおよびインストール

1. ターミナル(xterm, urxvtなど)を開き、インストール先のパスを環境変数 ZNK_INSTALL_DIR で指定します。



export ZNK_INSTALL_DIR=$HOME/install_dir


環境変数 ZNK_INSTALL_DIR で指定されたディレクトリが存在しない場合は自動的に生成されます。 Moaiの場合、$ZNK_INSTALL_DIR/moai-v$REL_VER（$REL_VERはMoaiのバージョン番号で例えば2.3など）という名前のディレクトリが生成され、 必要なファイルがそのディレクトリ配下へとインストールされます。

インストールされるファイルのうち、実行バイナリやライブラリなどプラットフォームに依存するファイル群は、 $ZNK_INSTALL_DIR/moai-v$REL_VER/bin/$PLATFORM という名前のディレクトリに配置されます。 ここで $PLATFORM はプラットフォームの種類を表します。 Linuxにおいては、環境変数ZNK_MUSL_DIRを指定した場合、$PLATFORM は linux_musl-* という文字列（*はCPUのタイプ）になり、 環境変数ZNK_MUSL_DIRを指定しない場合、$PLATFORM は linux-* という文字列になります。


Alpine Linux では、環境変数ZNK_MUSL_DIRを指定せずとも デフォルトで musl ライブラリを使用したビルドを行います。 この場合、$PLATFORM の値は上述の通り linux_musl-* ではなく linux-* などとなります。

Alpine Linux の場合、linux_musl-* と linux-* のどちらも musl を使ってのビルドとなります。 しかし linux-* の場合、通常は Alpine Linux 上でしか自立起動できないものとなります。

前のセクションでも述べた通り、これは musl 本体の問題というよりも動的リンカの種類と位置の問題です。 linux-* での実行バイナリのINTERPセクションの値は「/lib/ld-musl-x86_64.so.1」というように動的リンカの絶対パスが直に指定されたものになります。 他のLinuxでは通常このような名前の動的リンカは存在しませんから、 （Alpine Linuxと同じ動的リンカをそちらのLinuxにもインストールしない限りは）自立起動もできないことになります。


尚、自立起動に拘らないならば他のLinux上でも起動は可能です。

すなわち musl の動的リンカをいっしょに付属させ （muslはMITライセンスですので glibc とは異なりそのようなことが可能です）、 その動的リンカをインタプリタ言語のようにシェルから起動し、その引数として 実行バイナリを明示的に指定した上で起動する方法を前章で述べましたが、 その方法ならば他のLinux上でも起動させることができます。
Alpine Linux の場合、linux-* と linux_musl-* のどちらもmuslを使ってビルドされたバイナリであるため、 両者の違いは他のLinuxほどはありません。 以下に両者の違いを列挙します。


• linux_musl-*の場合（すなわち環境変数ZNK_MUSL_DIRを指定した場合）、 znk_projectが内蔵するmusl（そのソースコードはznk_project/musl以下にあります）をビルドします。 そのmuslは環境変数ZNK_MUSL_DIRで指定された場所に一旦インストールされますが、 以降のビルドではそのmuslを使います。
  
  
  尚、この内蔵muslはmusl Ver1.2.6をベースとして、 オリジナルのmuslにあった問題を少しだけ手直ししたものです。 具体的には以下の点について修正しています。
  
  

  • オリジナルではいくつかのコンパイル時警告が発生する。 無視しても構わないタイプのものだが、 ヘッダ include/endian.h で発生するものについては、 これ以降のコンパイル時のメッセージの邪魔になるので修正。
  
  
  • オリジナルではコンパイルオプションとして-sonameが指定されていない。 今、他のライブラリAや実行バイナリBから動的ライブラリXを動的リンクする場合を考える。 Xにsonameを指定しなかった場合、そのXの場所を表すパスの情報（DT_NEEDEDと呼ばれ、readelf -d コマンドで確認が可能） の値がAやB内に絶対パスで埋め込まれてしまう （gccないしはldがそのような仕様になっている）。 一方、Xにsonameを指定した場合、AやB内に埋め込まれる DT_NEEDEDの値はXのsonameとなる（つまり相対パスのような形で埋め込むことができる）。 DT_NEEDEDの値が絶対パスでは他のPCに移した場合に問題が生じる。 そのため、-sonameの指定は必ず行わなければならない。
    
    
  • オリジナルでは（おそらく少しでもパフォーマンスを重視しているためか） 動的ライブラリと静的ライブラリで異なるオブジェクトファイルを生成している （動的ライブラリの方のオブジェクトファイルは区別のため拡張子をloとしている）。 この違いは、動的ライブラリの方では -fPIC オプションを付けてコンパイルし、 静的ライブラリの方ではそれを付けずにコンパイルしている点だけである。 しかしそれだと同じC言語のファイルを二回冗長にビルドすることになるわけで、 単純にビルド全体にかかる時間も倍となる。 znk_project ではどのみち静的ライブラリの方はそれほど使用しないため、 このわずかなパフォーマンスの差も特に問題とならない。 そのため、動的ライブラリと静的ライブラリのどちらも -fPIC オプションを付けたオブジェクトファイルを 使用する形に修正している。
  一方、linux-*の場合（すなわち環境変数ZNK_MUSL_DIRを指定しない場合）、 Alpine Linuxシステム標準のmuslをそのまま使います。
  
  
  よって、linux-*の場合、znk_project内蔵muslのビルドも行われず、 libZnkのビルドからのスタートとなり、ビルド時間がそれだけ短く済みます。
  
  ただし、linux_musl-*の場合でも、単に「sh make_world.sh clean」だけでは musl 配下のオブジェクトファイルまでは clean されないため、 通常、musl の再ビルドは行われないことになります （これはznk_project/muslだけではなくznk_project/libresslなどでも同様です）。 そのため、二回目以降の「sh make_world.sh install」の実行では、 libZnkのビルドからのスタートとみなせます。
  
  尚、musl 内を本当に clean したい場合は該当ディレクトリに直接移動し、 そこにあるMakefileを実行して直接cleanします。
  
  
• linux_musl-* の場合、INTERPの値として「libc.so」がセットされます。 この場合、カレントディレクトリにlibc.soがある場合限定ですが、どんなLinuxでも自立起動ができます。 一方、linux-* の場合、INTERPの値として「/lib/ld-musl-x86_64.so.1」がセットされます。 この場合、Alpine Linux（あるいはこれに該当する動的リンカがインストールされているシステム）限定ですが、 どのディレクトリにいても自立起動ができます。


• linux_musl-* の場合、rarakuコマンドなど一部のコマンドがシェルスクリプトでラップされ、 実体のネイティブコマンドが raraku.bin などといった名前にリネームされます。 これにより、少し凝った仕掛けにはなってしまう嫌いはありますが、見かけ上自立起動できるかのように振舞わせることが可能となります。 一方、linux-* の場合、そのような変なことはせず、その他のシステムと同様に ネイティブライブラリをありのままの名前で作ります。


• linux_musl-* の場合、muslインストールディレクトリから libc.so が自動的にMoaiインストールディレクトリにコピーされます （よってインストールディレクトリをそのまま他のPCに持って行けば libc.so もいっしょに付属することになります）。 linux-* の場合はそのようなコピーは行われません。

Rarakuの場合も同様で、$ZNK_INSTALL_DIR/raraku-v$RRK_VER（$RRK_VERはRarakuのバージョン番号で例えば1.0など）という名前のディレクトリ配下にインストールされます。

尚、環境変数 ZNK_INSTALL_DIR が指定されていない場合は、src ディレクトリの一つ上の階層に install_dir というディレクトリが生成され、 その配下に moai-v$REL_VER や raraku-v$RRK_VER などが配置されます。


尚、環境変数INST_MACHINEに「x86」または「x64」を明示的に設定して上記を実行した場合は、それぞれ32bit版または64bit版バイナリが生成されます。 この環境変数を指定していない場合は、Makefile_linux.mak 内で uname -m コマンドが実行され、その結果により 32bit版か64bit版かが自動的に決定されます。


2. srcディレクトリへ移動し、以下のシェルスクリプトを実行します。



cd znk_project/src
sh ./make_world.sh install


これですべてのコンパイルおよびインストールが自動で行われます。


このシェルスクリプトにより、Makefile_linux.mak の存在する各ディレクトリへ自動的に移動しつつ make -f Makefile_linux.mak install が実行されます。 コンパイル後の実行バイナリは各ディレクトリ内のout_dirに格納されます。
インストール処理だけを省略したい、つまり純粋にコンパイルだけを行いたい場合は、 各々のディレクトリで直接「make -f Makefile_linux.mak」を実行した方がよいでしょう。 「sh ./make_world.sh」と実行することもできますが、 純粋にコンパイルだけでは必要なライブラリやツールがまだ所定の位置に配置されないため、 それらに依存するツールのコンパイルにおいて、リンクに失敗するかもしれません。

動作確認

cd $ZNK_INSTALL_DIR/moai-v2.3
sh moai.sh

Moai : config load OK.
Moai : target load OK.
Moai : analysis load OK.
Moai : Filter Loading [filters/….myf]
Moai : Plugin Loading [plugins/….so]
…
Moai : acceptable_host=[LOOPBACK]
Moai : blocking_mode=[0]
Moai : AutoGet PrivateIP=[192.168.…].
Moai : Listen port 8124...

Moai : ObserveR : 1-th sock events by select.

cd $ZNK_INSTALL_DIR/moai-v2.3
sh moai.sh -acceptable_any

BSD版をコンパイルする(FreeBSD/NetBSD/DragonFly/OpenBSD)

はじめに

違う！ソイツじゃない！

DragonFlyは比較的最近登場したBSD系のOSで、 他のBSD系との違いをざっくり言うなら「ディスクスペースを消耗しまくったり中で色々変なこと（例えば普通とは違う凝った並列処理など）をしてでも、 なるべく高速化をめざすOS」といった理解でとりあえずよいのではないでしょうか？ しかし「ディスクスペースを消耗しまくったり中で色々変なことをする」ということは、 ユーザに課される注意点もそれだけ増えるということです。

ちなみにこの記事でのスタンスはほぼその逆で、 ディスクスペースをなるべく節約し、確実に動作させることをめざします。 とはいえ、我々は別にDragonFlyのとっているスタンスに反対しているわけではなく、 そのようなスタンスにも一定の賛同はします。

そもそも昨今のマシンやOSなら、そこまで変なことしなくてもほとんどの用途において十分高速なはずです。 そのため、通常はDragonFlyを使う必要性はほぼないとは思いますが、 その一方で、非常な高速性を要求される用途では必要なこともあるのだろうとは思います。

極端な話、ユーザは100MBのディスクスペースを使っているつもりが、 実際には DragonFly 内部でそれよりもかなり多くのスペースを消耗しているといったことが起きるかもしれません。 また rm コマンドを実行したのにディスクの空きが増えるどころか 減ってしまうという奇妙なことが起きます。

これは DragonFlyで独自に使用されるファイルシステム Hammer2 に起因します。 Hammer2 を使用している場合、スナップショットと呼ばれるある種の履歴情報が 実際のファイルとは別に保持されます。 そのため余計なディスクスペースを消耗するのです。

また、このファイルシステムでは rm コマンドを実行しただけではファイルの実体は消去されません。 Windows などで言うところの「ゴミ箱」のような場所へ移動され、さらには「削除をした」という履歴情報が スナップショットに追加されますので、 結局、ディスクの空きが増えるどころかむしろ減ってしまうわけです。 これを完全に消去するには、「hammer2 bulkfree /」というかなり見慣れない（というよりほぼDragonFlyを使っているユーザにしかわからない） コマンドを実行する必要があります。 これがWindows などで言うところの「ゴミ箱を空にする」です。

通常、大きなファイルを rm コマンドで削除するのは、 ディスクの残りが切迫している場合が多いと思います。 そのような状況でユーザの意に反して逆にディスクの残りが減ってしまうのは、 状況を把握していないユーザからすればかなり混乱する挙動でしょう。

ちなみに Hammer2 以外のファイルシステムとして、Hammer や UFS を DragonFly のインストーラから選択できるようになっています。 ところがこれらを選択した場合、インストール先のハードディスク容量として、 Hammerの場合は 10GB、UFSの場合は 4GB以上のサイズが必須であるといった旨のメッセージが表示されます （もしもインストール先のディスクがそのサイズに満たない場合、これらのファイルシステムを選択することができません）。 ディスクスペースの消費を最小限としたい（目安としては一つのBSDにつきせいぜい3GB以下で済ませたい） 我々としてはこの要求水準は高すぎるため、この記事での選択肢としては Hammer2 一択となります。

あとこれは環境にもよるかもしれませんが、OSインストール時のファイルのコピーに失敗する場合があります。 例えばVirtualBox上でのインストールの場合、ファイル等コピー時にVirtualBoxごとクラッシュすることがあります （何度か試すと最後まで成功する場合もあり、現象にあまり再現性がありません）。

我々は同じVirtualBox上でその他のBSDもインストールして比較検証しておりますが、 このようなことは OpenBSD でも起こります （OpenBSDの場合、VirtualBoxごとクラッシュするようなことはありませんが、 ファイルのコピーに失敗後、インストーラが強制終了することがあります）。 一方、FreeBSD や NetBSD ではこのようなことは一切起こりません。

DragonFlyの場合、もしかすると hammer2 を 3GB のディスクで使用していることにに由来するクラッシュかもしれませんが、 その場合でも普通は「ディスクサイズが足りません」といったエラーが出て インストーラが中断する程度のことで済むでしょうから、VirtualBox との相性の問題かもしれません。

Close

必要なコマンド群

コンパイルおよびインストール

1. ターミナル(xterm, urxvtなど)を開き、インストール先のパスを環境変数 ZNK_INSTALL_DIR で指定します。



export ZNK_INSTALL_DIR=$HOME/install_dir


環境変数 ZNK_INSTALL_DIR で指定されたディレクトリが存在しない場合は自動的に生成されます。 Moaiの場合、$ZNK_INSTALL_DIR/moai-v$REL_VER（$REL_VERはMoaiのバージョン番号で例えば2.3など）という名前のディレクトリが生成され、 必要なファイルがそのディレクトリ配下へとインストールされます。

特にコンパイルされた実行バイナリやライブラリなどは、$ZNK_INSTALL_DIR/moai-v$REL_VER/bin/$PLATFORM という名前のディレクトリに配置されます。 ここで $PLATFORM は実行バイナリの種類を表し、例えばFreeBSDにおいては、freebsd-x86、freebsd-x64 といった文字列になります。


FreeBSD/NetBSD/DragonFly/OpenBSDの実行バイナリに互換性はありません。 そのため、これらに対応する$PLATFORMの値はそれぞれ freebsd-x64、netbsd-x64、dragonfly-x64、openbsd-x64 のようになり、 全て異なります。

尚、x86系CPU64bit版の場合、Windows界隈ではx64、オープンソース界隈ではx86_64という表記が主に使われます。 しかし znk_project では x64 という表記の方が短く、しかも x86 という表記と文字数が同じになるという理由でWindows流の表記で統一しています （ただしDarwinの場合はクロスコンパイルとの相性がよいi386とx86_64という表記を使っています）。 その他、target-tripletと呼ばれる表記方法もよく使われますが、 どのみち統一性が取れているとは現状では言いがたく、 ベンダー名など無駄に長い情報まで付加される表記であるため、そちらも採用していません。

Rarakuの場合も同様で、$ZNK_INSTALL_DIR/raraku-v$RRK_VER（$RRK_VERはRarakuのバージョン番号で例えば1.0など）という名前のディレクトリ配下にインストールされます。

尚、環境変数 ZNK_INSTALL_DIR が指定されていない場合は、src ディレクトリの一つ上の階層に install_dir というディレクトリが生成され、 その配下に moai-v$REL_VER や raraku-v$RRK_VER などが配置されます。


尚、環境変数INST_MACHINEに「x86」または「x64」を明示的に設定して上記を実行した場合は、それぞれ32bit版または64bit版バイナリが生成されます。 この環境変数を指定していない場合は、Makefile_bsd.mak（またはMakefile_linux.mak）内で uname -m コマンドが実行され、 その結果により 32bit版か64bit版かが自動的に決定されます。


2. システム標準にgcc が入っているのか llvm_clang が入っているのかを確認します。

単に「gcc」と実行し、「gcc: error: not input file」などといったエラーが出れば gcc が入っています。 あるいは単に「clang」と実行し、「clang: error: not input file」などといったエラーが出れば llvm_clang が入っています。 どちらも入っているケースはレアでしょうが、その場合はどちらでも構いません。 どちらも入っていない場合はどちらかをインストールしておく必要があります。

例えば、FreeBSD(この記事執筆時点での最新版はVer15.0)やOpenBSD（この記事執筆時点での最新版はVer7.8）をお使いの場合は、 llvm_clang が標準でインストールされており、 gcc は標準ではインストールされていないと思います。


古いバージョンのFreeBSDやOpenBSDでは gcc が標準でインストールされているかもしれません。

逆に、例えばNetBSD(この記事執筆時点での最新版はVer10.1)やDragonFly(この記事執筆時点での最新版はVer6.4.2)をお使いの場合は、 gcc が標準でインストールされており、 llvm_clang は標準ではインストールされていないと思います。


NetBSDの場合、"Minimal instration" でOSをインストールした場合は どのコンパイラも入っていない状態だと思います。 OSをインストール時に素直に "Compiler Tools" も追加しておいた方がよいでしょう。 それですべてが揃います。

"Minimal instration" の場合は、gcc や 付属する開発ツール、 C言語の標準ヘッダを別途 pkg_add コマンドなどでインストールする必要がありますが、 これはやや難しいかもしれません。 特にC言語の標準ヘッダが厄介で、該当するものがNetBSDのパッケージ配布サイトに存在しないように思えます。 これについては結局isoファイルに含まれる comp.txz から抽出するか、 pkgin コマンド（pkg_addの使いにくさを改良したもののようですが）を利用するしかないのかもしれません。

llvm_clang を使用する場合、環境変数 ZNK_LLVM_CLANG_DIR の設定が必須となります。

llvm_clang が標準でインストールされている場合、 /usr/bin/clang などが存在する状態のはずですので、以下のように設定することになります。



export ZNK_LLVM_CLANG_DIR=/usr



Makefile_bsd.mak（またはMakefile_linux.mak）は環境変数 ZNK_LLVM_CLANG_DIR が定義されている場合、 llvm_clang を使用したビルドに自動的に切り替えるようになっています。 そのため、llvm_clang を使用する場合、この環境変数 ZNK_LLVM_CLANG_DIR の定義は必須です。 たとえ単に「clang」と打ってllvm_clangが実行できるようになっていたとしてもです。

あるいは llvm_clang をパッケージでインストールした場合、 /usr/local/bin/clang などが存在する状態のはずですので、以下のように設定することになります。



export ZNK_LLVM_CLANG_DIR=/usr/local


あるいは /usr/pkg/bin/clang などが存在する状態であるかもしれません。 その場合は、以下のように設定することになります。



export ZNK_LLVM_CLANG_DIR=/usr/pkg




逆に gcc を使用する場合、環境変数 ZNK_LLVM_CLANG_DIR を設定してはいけません。 ZNK_LLVM_CLANG_DIR を設定してしまった場合は、一度ターミナルを閉じるか以下のようにして設定を解除しましょう。



unset ZNK_LLVM_CLANG_DIR


gcc が標準でインストールされている場合、 あるいはパッケージでインストールした場合、 いずれの場合も ZNK_LLVM_CLANG_DIR を設定せず、 つまり何もしない状態にしてください。 それによりデフォルトで gcc を使ったビルドが行われます。


3. srcディレクトリへ移動し、以下のシェルスクリプトを実行します。



cd znk_project/src
sh ./make_world.sh install


これですべてのコンパイルおよびインストールが自動で行われます。


このシェルスクリプトにより、Makefile_bsd.mak（または Makefile_linux.mak）の存在する各ディレクトリへ自動的に移動しつつ make -f Makefile_bsd.mak install または （gmake -f Makefile_linux.mak install） が実行されます。 コンパイル後の実行バイナリは各ディレクトリ内のout_dirに格納されます。
インストール処理だけを省略したい、つまり純粋にコンパイルだけを行いたい場合は、 各々のディレクトリで直接「make -f Makefile_bsd.mak」（または「gmake -f Makefile_linux.mak」）を実行した方がよいでしょう。 「sh ./make_world.sh」と実行することもできますが、 純粋にコンパイルだけでは必要なライブラリやツールがまだ所定の位置に配置されないため、 それらに依存するツールのコンパイルにおいて、リンクに失敗するかもしれません。

動作確認

cd $ZNK_INSTALL_DIR/moai-v2.3
sh moai.sh

Moai : config load OK.
Moai : target load OK.
Moai : analysis load OK.
Moai : Filter Loading [filters/….myf]
Moai : Plugin Loading [plugins/….so]
…
Moai : acceptable_host=[LOOPBACK]
Moai : blocking_mode=[0]
Moai : AutoGet PrivateIP=[192.168.…].
Moai : Listen port 8124...

Moai : ObserveR : 1-th sock events by select.

cd $ZNK_INSTALL_DIR/moai-v2.3
sh moai.sh -acceptable_any

Android版をコンパイルする

はじめに

必要なコマンド群

Android NDKの入手

• Windowsの場合
1. Android NDKをダウンロードおよびインストールしたいディレクトリの親となるディレクトリを（手動で）予め作って用意しておきます。
どこでも構いませんが、ここでは例えば E:\Android というディレクトリとしましょう。


実際には、さらにこの直下に android-ndk-r14b というディレクトリが自動的に作られます。 今回の例ですと、E:\Android\android-ndk-r14b が最終的なAndroid NDKのインストールディレクトリとなります。 ただしこの android-ndk-r14b ディレクトリはまだ作らないでください。 E:\Android ディレクトリだけを作っておきます。

このandroid-ndk-r14b内は最終的にはおよそ1GB程度になります （install_ndkスクリプトはandroid-ndk-r14b内にある不要なディレクトリを自動的に圧縮し、なるべくディスクサイズを抑えるようにしています。この圧縮を行わない場合2GB以上にもなってしまいます）。

ただし途中の作業において、zipファイルをダウンロードおよび解凍するなどで一時的な作業スペースが必要となります。 そのため、実際には3GB程度以上のディスクの空きは必要です。


2. 環境変数ZNK_ANDROID_NDK_DIRにAndroid NDKをダウンロードおよびインストールしたいディレクトリのフルパスを指定します。

このパスは上記で作成したディレクトリの後ろにさらに「\android-ndk-r14b」を連結したものになります。 今回の例ですと、E:\Android\android-ndk-r14b を値として指定します。

環境変数ZNK_ANDROID_NDK_DIRはWindowsの環境変数設定ダイアログから設定することもできますが、 OS全体にその効果を波及させたくない場合は src\make_apk\moai\setenv.bat ファイル内に記述しておきましょう。 これにより、MoaiのビルドでAndroid NDKを使う場合のみ一時的にこの環境変数を有効にさせることができます。 テキストエディタでこのsetenv.batファイルを開き、「set ZNK_ANDROID_NDK_DIR=」とある文を探します。 「=」の右側の部分が指定すべきフルパスとなるように修正するとよいでしょう。 今回の例では、以下のようになります。



set ZNK_ANDROID_NDK_DIR=E:\Android\android-ndk-r14b



batファイルにおける set コマンドでは「=」の右側に指定すべき値を記述します。 ただしこのとき「=」の左右に余分な半角スペースなどを挿入してはいけません。 半角スペースそのものが値の一部として認識されてしまうからです。 また右側に指定する値はダブルクォートで囲ってもいけません。 ダブルクォート文字そのものが値の一部として認識されてしまうからです。

ちなみにbatファイルにおいて REM で始まる行はコメントアウトと呼ばれ、その行がなかったものとみなされます。 これは通常はコード内で説明を記述する用途で使われます。 その他、設定の候補を一時的に有効/無効にしたりするのにも便利です。


3. src\make_apk\moai\install_ndk.batをダブルクリックして実行します。
   
   
   install_sdk.bat というファイルもありますが、そちらではなくinstall_ndk.batの方です。
   
   これによりAndroid NDKのダウンロードとインストールが自動的に行われます。
   
   


• Linuxの場合
1. Android NDKをダウンロードおよびインストールしたいディレクトリの親となるディレクトリを（手動で）予め作って用意しておきます。
どこでも構いませんが、ここでは例えばホームディレクトリ直下のDownloads/Android というディレクトリとしましょう。


実際には、さらにこの直下に android-ndk-r14b というディレクトリが自動的に作られます。 今回の例ですと、$HOME/Downloads/Android/android-ndk-r14b が最終的なAndroid NDKのインストールディレクトリとなります。 ただしこの android-ndk-r14b ディレクトリはまだ作らないでください。 ホームディレクトリ直下にDownloads/Android ディレクトリだけを作っておきます。

このandroid-ndk-r14b内は最終的にはおよそ1GB程度になります （install_ndkスクリプトはandroid-ndk-r14b内にある不要なディレクトリを自動的に圧縮し、なるべくディスクサイズを抑えるようにしています。この圧縮を行わない場合2GB以上にもなってしまいます）。

ただし途中の作業において、zipファイルをダウンロードおよび解凍するなどで一時的な作業スペースが必要となります。 そのため、実際には3GB程度以上のディスクの空きは必要です。


2. 環境変数ZNK_ANDROID_NDK_DIRにAndroid NDKをダウンロードおよびインストールしたいディレクトリのフルパスを指定します。

このパスは上記で作成したディレクトリの後ろにさらに「/android-ndk-r14b」を連結したものになります。 今回の例ですと、$HOME/Downloads/Android/android-ndk-r14b を値として指定します。

以下のようなコマンドを実行する形になります。



export ZNK_ANDROID_NDK_DIR="$HOME/Downloads/Android/android-ndk-r14b"



Linux等のシェルスクリプトにおいては、「=」の右側に指定すべき値を記述します。 ただしこのとき「=」の左右に余分な半角スペースなどを挿入してはいけません。「=」の左側が独立したコマンドとみなされてしまうためです。 右側に指定する値はダブルクォートで囲って指定しておいた方が賢明でしょう。 その方が値に半角スペースなどを含む場合にも対応できるからです（半角スペースが存在しないことが明らかな場合はダブルクォートを省略することもできます）。

ただし単に上記のコマンドを実行しただけですと、一度ターミナルを閉じたら次回もまたこれを打ち込む必要があります。

この環境変数ZNK_ANDROID_NDK_DIRの指定は ~/.bashrc 内に記述しておくことで永続的な設定とすることができますが、 OS全体にその効果を波及させたくない場合は src/make_apk/moai/setenv.sh ファイル内に記述しておきましょう。 これにより、MoaiのビルドでAndroid NDKを使う場合のみ一時的にこの環境変数を有効にさせることができます。 テキストエディタでこのsetenv.shファイルを開き、「export ZNK_ANDROID_NDK_DIR=」とある文を探します。 「=」の右側の部分が「"$HOME/Downloads/Android/android-ndk-r14b"」となるように修正するとよいでしょう。 今回の例では、以下のようになります（上記のコマンドとまったくいっしょです）。



export ZNK_ANDROID_NDK_DIR="$HOME/Downloads/Android/android-ndk-r14b"





3. src/make_apk/moai ディレクトリへ移動し、install_ndk.sh を実行してください。


install_sdk.sh というファイルもありますが、そちらではなくinstall_ndk.shの方です。

以下のような流れになります。



cd src/make_apk/moai
sh install_ndk.sh


これによりAndroid NDKのダウンロードとインストールが自動的に行われます。

Android版Moaiのコンパイル(Windows PC上で行う場合)

1. 「3. switch debug-mode」を何回か選んでDEBUG_MODEを「optimize」にします。
2. 「4. switch mkfid」を何回か選んでMKF_IDを「android」にします。
3. 「5. switch machine」を何回か選んでMACHINEを「armeabi-v7a」等にします（ご利用のスマホのCPUに応じて選びます）。
4. 「1. make install」を選びます。

Android版Moaiのコンパイル(Linux PC上で行う場合)

sh make_world_android.sh install

env INST_MACHINE=armeabi-v7a sh make_world_android_one.sh install

env INST_MACHINE=arm64-v8a sh make_world_android_one.sh install

env INST_MACHINE=x86 sh make_world_android_one.sh install

env INST_MACHINE=x86_64 sh make_world_android_one.sh install

コンパイルの次にすべきこと

export PATH=$PATH:$ZNK_ANDROID_NDK_DIR:$ZNK_ANDROID_NDK_DIR/build

cd libZnk/mkf_android
ndk-build

Android APK版を作成する

Introduction of Making APK

• Windowsの場合

Moai本体の（ネイティブバイナリの）コンパイルはWindows2000でも可能ですが、このapk版の作成に関してはWindows XP以降が必要となります。 apk の作成においては OpenJDKが必須となりますが、 現在、ネット上で配布されているOpenJDKのうち、Windows2000で動作するものの入手は困難です。


• Linuxの場合

64bit版Linuxが必要となります。 apk の作成においては OpenJDKが必須となりますが、 現在、ネット上で配布されているOpenJDKのうち、Linux 32bit版で動作するものの入手は困難です。 またそもそもAndroid NDK自体が32bit版Linuxに対応しておりません。

APKを作成するために必要なツール/ライブラリ群のインストール

• Windowsの場合
1. 必要なツール/ライブラリ群をダウンロードおよびインストールしたいディレクトリを決め、その親となるディレクトリを（手動で）予め作って用意しておきます。
どこでも構いませんが、この記事では例えば E:\Android というディレクトリとしましょう。


2. 上記で作成したディレクトリの直下にさらに以下のディレクトリを（手動で）予め作って用意しておきます。 またそれぞれについて必要な環境変数を設定します。


• OpenJDKディレクトリ

このディレクトリ配下にOpenJDKをインストールするものとします。 このディレクトリは空のままで構いません。 今回の例では、E:\Android\OpenJDK という構成になります。

環境変数ZNK_OPENJDK_DIRにこのディレクトリのフルパス（E:\Android\OpenJDK）を指定してください。 src\make_apk\moai\setenv.bat 内に記述しておくとよいでしょう。 指定方法の詳細についてはAndroid NDKの設定の時と同様なので説明は割愛します。

インストール後のサイズはおよそ200MB程度になります。


• gradleディレクトリ

このディレクトリ配下にGradleをインストールするものとします。 このディレクトリは空のままで構いません。 今回の例では、E:\Android\gradle という構成になります。

環境変数GRADLE_USER_HOMEにこのディレクトリのフルパス（E:\Android\gradle）を指定してください。 src\make_apk\moai\setenv.bat 内に記述しておくとよいでしょう。 指定方法の詳細についてはAndroid NDKの設定の時と同様なので説明は割愛します。

インストール後のサイズはおよそ100MB程度になります。 ただしgradleを初回実行時、Android Gradle Pluginと呼ばれるものも自動的にダウンロードされますが、 それらの関連ファイルを含めると最終的に200MB以上に膨れ上がる場合もあります。


• sdk_rootディレクトリ

このディレクトリ配下にAndroid SDKをインストールするものとします（Android NDKと名前が似てますが別ものです）。 このディレクトリは空のままで構いません。 今回の例では、E:\Android\sdk_root という構成になります。

環境変数ANDROID_SDK_ROOTにこのディレクトリのフルパス（E:\Android\sdk_root）を指定してください。 src\make_apk\moai\setenv.bat 内に記述しておくとよいでしょう。 指定方法の詳細についてはAndroid NDKの設定の時と同様なので説明は割愛します。

インストール後のサイズはおよそ400MB程度になります。


3. src\make_apk\moai\install_sdk.batをダブルクリックして実行します。
   
   
   install_ndk.bat ではなくinstall_sdk.batの方です。
   
   これにより上記の各ディレクトリへ必要なツール/ライブラリ群のダウンロードとインストールが自動的に行われます。
   
   


• Linuxの場合
1. 必要なツール/ライブラリ群をダウンロードおよびインストールしたいディレクトリを決め、その親となるディレクトリを（手動で）予め作って用意しておきます。
どこでも構いませんが、この記事では例えば ~/Downloads/Android というディレクトリとしましょう。


2. 上記で作成したディレクトリの直下にさらに以下のディレクトリを（手動で）予め作って用意しておきます。 またそれぞれについて必要な環境変数を設定します。

環境変数の設定は src/make_apk/moai/setenv.sh 内に記述しておくとよいでしょう。 設定方法の詳細についてはAndroid NDKの時と同様なのでここでの説明は割愛します。


• OpenJDKディレクトリ

このディレクトリ配下にOpenJDKをインストールするものとします。 このディレクトリは空のままで構いません。 今回の例では、$HOME/Downloads/Android/OpenJDK という構成になります。

環境変数ZNK_OPENJDK_DIRにこのディレクトリのフルパス（$HOME/Downloads/Android/OpenJDK）を指定してください。

インストール後のサイズはおよそ200MB程度になります。


• gradleディレクトリ

このディレクトリ配下にGradleをインストールするものとします。 このディレクトリは空のままで構いません。 今回の例では、$HOME/Downloads/Android/gradle という構成になります。

環境変数GRADLE_USER_HOMEにこのディレクトリのフルパス（$HOME/Downloads/Android/gradle）を指定してください。

インストール後のサイズはおよそ100MB程度になります。 ただしgradleを初回実行時、Android Gradle Pluginと呼ばれるものもダウンロードされますが、 それらの関連ファイルを含めると最終的に200MB以上に膨れ上がる場合もあります。


• sdk_rootディレクトリ

このディレクトリ配下にAndroid SDKをインストールするものとします（Android NDKと名前が似てますが別ものです）。 このディレクトリは空のままで構いません。 今回の例では、$HOME/Downloads/Android/sdk_root という構成になります。

環境変数ANDROID_SDK_ROOTにこのディレクトリのフルパス（$HOME/Downloads/Android/sdk_root）を指定してください。

インストール後のサイズはおよそ400MB程度になります。


3. src/make_apk/moai ディレクトリへ移動し、install_sdk.sh を実行してください。


install_ndk.sh ではなくinstall_sdk.shの方です。

以下のような流れになります。



cd src/make_apk/moai
sh install_sdk.sh


これにより上記の各ディレクトリへ必要なツール/ライブラリ群のダウンロードとインストールが自動的に行われます。

APKの生成

• Windowsの場合
1. src/make_apk/moaiへ移動し、make_assets.bat をダブルクリックして実行します。

これはandroid-v2.*-{MACHINE}ディレクトリからネイティブバイナリ以外のすべての必要なファイルを src/make_apk/moai/assets_draft/common配下へコピーし、それを元にsrc/make_apk/moai/assets_draft/common.zipを作ります。

またandroid-v2.*-{MACHINE}ディレクトリからネイティブバイナリを src/make_apk/moai/assets_draft/bin配下へコピーし、それを元にsrc/make_apk/moai/assets_draft/bin.zipを作ります。

最後にsrc/make_apk/moai/assets_draft/common.zip、src/make_apk/moai/assets_draft/bin.zip を src/make_apk/moai/app/src/main/assets 配下へコピーします。 これらのzipファイルは最終的にapkファイルに取り込まれます。


2. src/make_apk/moaiへ移動し、make_apk.bat をダブルクリックして実行します。

これは Gradle を使って残りの処理のすべてを行います。

まず初回のGradleの起動においては、Android Gradle Plugin がまだPC上にインストールされていないため、 GradleはこれをGoogle等のリポジトリから自動的にダウンロードしてインストールします。 このような処理が入るため、これにはかなり時間がかかります。 ただし二回目以降のGradleの起動ではこの処理はスキップできるはずです。

次にGradleは、src/make_apk/moai/app/src/main/jniLibs 配下に置かれたネイティブライブラリ(libZnk、libRrk, libRano, libMoai, libtsl-17)を apk内へ取り込みます。

またGradleは src/make_apk/moai/app/src/main/java/znkproject/moai にある javaソースをコンパイルし、 生成したclassファイルをapk内へ取り込みます。

上記がすべてエラーなく終了した場合、最後にsrc/make_apk/moai直下にmoai-v2.*-android.apkというファイルが生成され、 BUILD SUCCESS（成功）となります。 このapkファイルがこのセクションで最終的に作成したかったものとなります。 すべてが滞りなく成功していれば、現在Moaiの公式サイトでダウンロードできるapkと（タイムスタンプなどを除き）基本的に同じものが生成されているはずです。




• Linuxの場合
1. src/make_apk/moaiへ移動し、make_assets.sh を実行します。

以下のような流れになります。



cd src/make_apk/moai
sh make_assets.sh


これはandroid-v2.*-{MACHINE}ディレクトリからネイティブバイナリ以外のすべての必要なファイルを src/make_apk/moai/assets_draft/common配下へコピーし、それを元にsrc/make_apk/moai/assets_draft/common.zipを作ります。

またandroid-v2.*-{MACHINE}ディレクトリからネイティブバイナリを src/make_apk/moai/assets_draft/bin配下へコピーし、それを元にsrc/make_apk/moai/assets_draft/bin.zipを作ります。

最後にsrc/make_apk/moai/assets_draft/common.zip、src/make_apk/moai/assets_draft/bin.zip を src/make_apk/moai/app/src/main/assets 配下へコピーします。 これらのzipファイルは最終的にapkファイルに取り込まれます。


2. src/make_apk/moaiへ移動し、make_apk.sh を実行します。

以下のような流れになります。



cd src/make_apk/moai
sh make_apk.sh


これは Gradle を使って残りの処理のすべてを行います。

まず初回のGradleの起動においては、Android Gradle Plugin がまだPC上にインストールされていないため、 GradleはこれをGoogle等のリポジトリから自動的にダウンロードしてインストールします。 このような処理が入るため、これにはかなり時間がかかります。 ただし二回目以降のGradleの起動ではこの処理はスキップできるはずです。

次にGradleは、src/make_apk/moai/app/src/main/jniLibs 配下に置かれたネイティブライブラリ(libZnk、libRrk, libRano, libMoai, libtsl-17)を apk内へ取り込みます。

またGradleは src/make_apk/moai/app/src/main/java/znkproject/moai にある javaソースをコンパイルし、 生成したclassファイルをapk内へ取り込みます。

上記がすべてエラーなく終了した場合、最後にsrc/make_apk/moai直下にmoai-v2.*-android.apkというファイルが生成され、 BUILD SUCCESS（成功）となります。 このapkファイルがこのセクションで最終的に作成したかったものとなります。 すべてが滞りなく成功していれば、現在Moaiの公式サイトでダウンロードできるapkと（タイムスタンプなどを除き）基本的に同じものが生成されているはずです。

トラブルシューティング

/*****************************************************************************/
/* User Customize */

app_abi = [
	"armeabi-v7a",
	"arm64-v8a",
	"x86",
	"x86_64",
	//"armeabi",
]

//agp_ver = AGP_e_2_2_0
//agp_ver = AGP_e_2_3_0
//agp_ver = AGP_e_3_1_0
//agp_ver = AGP_e_4_0_0
//agp_ver = AGP_e_7_0_0

/* endof User Customize */
/*****************************************************************************/

//agp_ver = AGP_e_2_2_0
agp_ver = AGP_e_2_3_0 /* Windows XP OK */

agp_ver = AGP_e_2_3_0

//agp_ver = AGP_e_2_2_0
//agp_ver = AGP_e_2_3_0
//agp_ver = AGP_e_3_1_0
//agp_ver = AGP_e_4_0_0
//agp_ver = AGP_e_7_0_0

//agp_ver = AGP_e_2_2_0
//agp_ver = AGP_e_2_3_0
//agp_ver = AGP_e_3_1_0
agp_ver = AGP_e_4_0_0
//agp_ver = AGP_e_7_0_0

//agp_ver = AGP_e_2_2_0
//agp_ver = AGP_e_2_3_0
agp_ver = AGP_e_3_1_0
//agp_ver = AGP_e_4_0_0
//agp_ver = AGP_e_7_0_0

sh install_sdk.sh

import rrk_script/cfg_gen_impl

varia app_abi conststr[]
varia agp_ver AGPVer = CfgGen_getDefaultAGPVer()


/*****************************************************************************/
/* User Customize */

app_abi = [
	"armeabi-v7a",
	"arm64-v8a",
	"x86",
	"x86_64",
	//"armeabi",
]

//agp_ver = AGP_e_2_2_0
//agp_ver = AGP_e_2_3_0
//agp_ver = AGP_e_3_1_0
//agp_ver = AGP_e_4_0_0
//agp_ver = AGP_e_7_0_0

/* endof User Customize */
/*****************************************************************************/


return CfgGen_main( agp_ver, app_abi )

Android実機へ転送する

USBでスマホと接続し、Android側のディレクトリをPC側から参照することで転送

ネットを経由

USBでスマホと接続し、adbコマンドにより直接インストールする（開発者向け）

• 「設定」⇒「端末オプション」⇒「開発者オプション」から「USBデバッグ」をONにしておく。


ただし「開発者オプション」の項目はデフォルトでは無効になっています。 これを有効にさせるには「ビルド番号」を7回ほど連続でタップします。 「ビルド番号」は「設定」⇒「端末オプション」⇒「Fireタブレットのバージョン情報」⇒「ビルド番号」にあります。


機種によっては「設定」⇒「端末オプション」⇒「ソフトウェア情報」⇒「ビルド番号」になっていることもあります。 また機種によっては、以下のように名前が異なることもあります。
• 「開発者オプション」
「開発者モード」となっていることがあります。


• 「ビルド番号」
「シリアル番号」となっていることがあります。


• 「USBデバッグ」
「ADBを有効にする」となっていることがあります。


• 「設定」⇒「接続デバイス」⇒「USB」から「ファイル転送」を選んで置く。


ただし機種によってはこれは必要ないかもしれません。

• Windowsの場合

Windowsで adb コマンドを使う場合、まず「Google USB Driver」（Googleが提供するadb用ドライバ）をWindowsにインストールしておく必要があります。


名前は「Google USB Driver」となっていますが、あくまでUSBを繋いでadbコマンドを使う場合のみ必要となります。 単にUSBでPCとスマホと接続し、Android側のディレクトリをPC側から参照したりファイルを転送したいだけの場合、 このドライバをインストールする必要はありません。
FireHD で adbコマンドを使う場合のWindows用ドライバとして、Amazonが kindle_fire_usb_driver というものを配布しています。 しかしこれはうまくインストールできない場合があるため、避けた方が無難です。 FireHDであっても「Google USB Driver」をインストールすることをお勧めします。

これのインストールがまだの場合は、以下の「Google USB Driverをインストールする」を参照し、 まずはこのインストールを済ませてください（このインストール作業ではスマホをUSBで接続する必要もあります）。

Google USB Driverをインストールする
「Google USB Driver」は以下からダウンロードできます。

https://dl.google.com/android/repository/usb_driver_r13-windows.zip

上記のURLはAndroid Developersの以下のサイトにあるリンクの単なる抜粋です。

https://developer.android.com/studio/run/win-usb

ダウンロードが終わったらこれを適当なディレクトリで解凍しておきます。 例えば、E:\Android\usb_driver ディレクトリへ解凍したとしましょう。

インストール手順については、こちらのサイトに書かれた解説がかなり詳しいかと思いますが、 ここでも簡潔な手順を以下に示します。


1. Windows PCとスマホをUSBで繋ぎます。

繋いでおかないとデバイスマネージャに「Fire」という項目が現れません。


2. デバイスマネージャを開きます。

「ほかのデバイス」⇒「Fire」となっている項目があるはずです。 あるいは過去に一度このドライバをインストールしたことがある場合、「ADB Interface」という名前になっているかもしれません。 これを右クリックし、開いたコンテキストメニューから「ドライバソフトウェアの更新」を選びます。


3. 「ドライバソフトウェアの更新」ダイアログが表示されます。

ダイアログ上部に「どのような方法でドライバソフトウェアを検索しますか？」と表示されます。 「コンピュータを参照してドライバソフトウェアを検索します」を選びます。


4. ダイアログ上部に「コンピュータ上のドライバソフトウェアを参照します」と表示されます。

このときダイアログ下部に「コンピュータ上のデバイスドライバの一覧から選択します」が表示されますので それをクリックします。


5. ダイアログ上部に「次の一覧からデバイスの種類を選択してください」と表示されることがあります（されない場合もあります）。

このダイアログが表示された場合はスキップし、右下にある「次へ」ボタンをを押します。


6. ダイアログ上部に「このハードウェアのためにインストールするデバイスドライバを選択してください」と表示されます。

「ディスク使用」と書かれたボタンを押します。


7. 「フロッピーディスクからインストール」ダイアログが表示されます。

一番右下にある「参照」ボタンを押します。


ダイアログのタイトルには「フロッピーディスク」と書かれてはありますが、この作業でフロッピーディスクを使うことは一切ありません。


8. 「ファイルの場所」ダイアログ表示がされます。

ここで先ほど解凍したディレクトリ内へ移動します （今回の例ですとE:\Android\usb_driverです）。 トップディレクトリに android_winusb.inf ファイルが存在すると思いますので、 それを選択して「開く」ボタンを押してください。


9. 「フロッピーディスクからインストール」ダイアログが再度、最前面に表示されます。

「製造元のファイルのコピー元」欄の表示が今選択したandroid_winusb.infが置かれたディレクトリのパスになっていることを確認します（android_winusb.infそのものではなく、それが置かれたディレクトリのパスです）。 確認しましたら「OK」ボタンを押します。


10. ダイアログ上部に「このハードウェアのためにインストールするデバイスドライバを選択してください」と表示されます。

「モデル」とある欄に「Android ADB Interface」という項目があることを確認し、それをクリックしてください。 さらに「次へ」ボタンを押します。


11. 「ドライバの更新警告」ダイアログが表示されます。

「はい」を押してください。


このダイアログには「Windowsによってこのデバイスドライバがハードウェアと互換性があることを確認できなかったため このデバイスドライバをインストールしないことをお勧めします」などと表記されていると思いますが、 これは単にWindowsのDBにGoogle USB Driverの情報が登録されていないというだけの話なので 全く気にする必要はありません。


12. さらに「Windowsセキュリティ」ダイアログが表示される場合があります（されない場合もあります）。

発行元が「Google LLC」となっていることを確認し、「インストール」を押してください。


13. ダイアログ上部に「ドライバソフトウェアが正常に更新されました」と表示されます。

その下に「Android ADB Interface」と書かれてあることを確認してください。 これでインストールは完了です。 「閉じる」ボタンを押してください。


14. コンピュータの再起動を促すメッセージが表示される場合があります（されない場合もあります）。

これが表示された場合でも今すぐに再起動する必要はありませんが、キリのよいところで再起動しましょう。


15. 念のため、デバイスマネージャ内に、「Android Phone」⇒「Android ADB Interface」といった項目があることを確認します （Android Phoneとある項目の頭にある小さな三角ボタンを押すと展開されます）。

これがあればドライバのインストールに成功しています。
Close


スマホに初めて接続されたPCの場合、ドライバのインストール完了後に「USBデバッグを許可しますか？」といったダイアログが（スマホ側の画面に）表示されることがあります。 その場合はそこで「OK」を押します。 ここで「OK」を押して許可設定にしておかないと以降のadbコマンドの実行に失敗してしまいます。

それでは adb コマンドの実行に移ります。 スマホとPCがUSB接続されている状態で以下を実行してください。


1. src/make_apk/moai/adb 内へ移動し、adb_start_server.bat を実行。

以下のように表示されれば成功です。 このメッセージはadb deamonというプログラムがPC上で起動し、スマホとの通信準備が整ったことを意味します （この段階ではまだapkファイルは転送されていません）。



deamon started successfully

2. src/make_apk/moai/adb 内へ移動し、adb_install_apk.bat を実行。

以下のように表示されれば成功です。 成功するとスマホへapkファイルが転送され、さらにインストールまで行われます。



Performing Push Install
Success





• Linuxの場合

スマホとPCがUSB接続されている状態で以下を実行してください。


adb_start_server.sh 内では sudo コマンドを伴って adb コマンド呼び出しています。 そのためお使いのLinuxで sudo コマンドが使える状態である必要があります。


1. src/make_apk/moai/adb 内へ移動し、adb_start_server.sh を実行。

以下のように実行します。



cd src/make_apk/moai/adb
sh adb_start_server.sh


以下のように表示されれば成功です。 このメッセージはadb deamonというプログラムがPC上で起動し、スマホとの通信準備が整ったことを意味します （この段階ではまだapkファイルは転送されていません）。



deamon started successfully



2. src/make_apk/moai/adb 内へ移動し、adb_install_apk.sh を実行。

以下のように実行します。



cd src/make_apk/moai/adb
sh adb_install_apk.sh


以下のように表示されれば成功です。 成功するとスマホへapkファイルが転送され、さらにインストールまで行われます。



Performing Push Install
Success

Performing Push Install
adb: error: failed to get feature set: no devices/emulators found

Performing Streamed Install

adb: failed to install moai-v2.3-android.apk:
Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package znkproject.moai signatures do not match previously installed version; ignoring!]

MacOSX(Darwin)版をコンパイルする(darwin8/darwin17)

MacOSX(Darwin)版について

必要なコマンド群

コンパイルおよびインストール

1. Darwin ターミナルを開き、インストール先のパスを環境変数 ZNK_INSTALL_DIR で指定します。



export ZNK_INSTALL_DIR=$HOME/install_dir


環境変数 ZNK_INSTALL_DIR で指定されたディレクトリが存在しない場合は自動的に生成されます。 Moaiの場合、$ZNK_INSTALL_DIR/moai-v$REL_VER（$REL_VERはMoaiのバージョン番号で例えば2.3など）という名前のディレクトリが生成され、 必要なファイルがそのディレクトリ配下へとインストールされます。

特にコンパイルされた実行バイナリやライブラリなどは、$ZNK_INSTALL_DIR/moai-v$REL_VER/bin/$PLATFORM という名前のディレクトリに配置されます。 ここで $PLATFORM は実行バイナリの種類を表し、例えばDarwinにおいては、darwin-i386、darwin-x86_64 といった文字列になります。 Rarakuの場合も同様で、$ZNK_INSTALL_DIR/raraku-v$RRK_VER（$RRK_VERはRarakuのバージョン番号で例えば1.0など）という名前のディレクトリ配下にインストールされます。

尚、環境変数 ZNK_INSTALL_DIR が指定されていない場合は、src ディレクトリの一つ上の階層に install_dir というディレクトリが生成され、 その配下に moai-v$REL_VER や raraku-v$RRK_VER などが配置されます。


尚、環境変数INST_MACHINEに「i386」または「x86_64」を明示的に設定して上記を実行した場合は、それぞれ32bit版または64bit版バイナリが生成されます （ただしdarwinのバージョンによってはどちらか一方が不可能であるかもしれません）。 この環境変数を指定していない場合は、Makefile_darwin.mak 内で uname -m と uname -a コマンドの両方が実行され、 その結果により 32bit版か64bit版かが自動的に決定されます。 特にDarwinのunameでは i386 と x86_64 のいずれでも「uname -m」だけでは単に「x86」という文字列が返されます。 そのため、さらに「uname -a」コマンドの出力で「i386」か「x86_64」のどちらなのかを切り分けています。


2. darwin17をお使いの場合のみ、Darwin ターミナルより、llvm_clangのインストール先を環境変数 ZNK_LLVM_CLANG_DIR で指定します。

darwin17では /usr/bin/clang などが存在する状態のはずですので、 以下のように設定することになります。



export ZNK_LLVM_CLANG_DIR=/usr


逆にdarwin8をお使いの方は、llvm_clang はインストールされておらず gcc がインストールされた状態でしょうから、 （別途llvm_clangがインストールされていない限りは）この環境変数 ZNK_LLVM_CLANG_DIR を指定してはいけません。

Makefile_darwin.mak は環境変数 ZNK_LLVM_CLANG_DIR が定義されている場合、 llvm_clang を使用したビルドに自動的に切り替えるようになっています。 そのため、darwin17の場合、この環境変数 ZNK_LLVM_CLANG_DIR の定義は必須です。 たとえ単に「clang」と打ってllvm_clangが実行できるようになっていたとしてもです。


3. srcディレクトリへ移動し、以下のシェルスクリプトを実行します。



cd znk_project/src
sh ./make_world.sh install


これですべてのコンパイルおよびインストールが自動で行われます。


このシェルスクリプトにより、Makefile_darwin.mak の存在する各ディレクトリへ自動的に移動しつつ make -f Makefile_darwin.mak install が実行されます。 コンパイル後の実行バイナリは各ディレクトリ内のout_dirに格納されます。
インストール処理だけを省略したい、つまり純粋にコンパイルだけを行いたい場合は、 各々のディレクトリで直接「make -f Makefile_darwin.mak」を実行した方がよいでしょう。 「sh ./make_world.sh」と実行することもできますが、 純粋にコンパイルだけでは必要なライブラリやツールがまだ所定の位置に配置されないため、 それらに依存するツールのコンパイルにおいて、リンクに失敗するかもしれません。

動作確認

Moai : config load OK.
Moai : target load OK.
Moai : analysis load SKIP.
Moai : Filter Loading [filters/….myf]
Moai : Plugin Loading [plugins/….dylib]
…
Moai : acceptable_host=[LOOPBACK]
Moai : blocking_mode=[0]
Moai : AutoGet PrivateIP=[192.168.…].
Moai : Listen port 8124...

Moai : ObserveR : 1-th sock events by select.

MacOSX(Darwin)版をクロスコンパイルする(darwin17)

はじめに

必要なコマンド群

osxcrossの概要とディレクトリの準備

osxcrossがサポートしているアーキテクチャとバージョン

case $SDK_VERSION in
  10.4*)  TARGET=darwin8;  X86_64H_SUPPORTED=0; I386_SUPPORTED=1; NEED_TAPI_SUPPORT=0; OSX_VERSION_MIN_INT=10.4;  ;;
  10.5*)  TARGET=darwin9;  X86_64H_SUPPORTED=0; I386_SUPPORTED=1; NEED_TAPI_SUPPORT=0; OSX_VERSION_MIN_INT=10.5;  ;;
  10.6*)  TARGET=darwin10; X86_64H_SUPPORTED=0; I386_SUPPORTED=1; NEED_TAPI_SUPPORT=0; OSX_VERSION_MIN_INT=10.5;  ;;
  10.7*)  TARGET=darwin11; X86_64H_SUPPORTED=0; I386_SUPPORTED=1; NEED_TAPI_SUPPORT=0; OSX_VERSION_MIN_INT=10.5;  ;;
  10.8*)  TARGET=darwin12; X86_64H_SUPPORTED=1; I386_SUPPORTED=1; NEED_TAPI_SUPPORT=0; OSX_VERSION_MIN_INT=10.5;  ;;
  10.9*)  TARGET=darwin13; X86_64H_SUPPORTED=1; I386_SUPPORTED=1; NEED_TAPI_SUPPORT=0; OSX_VERSION_MIN_INT=10.5;  ;;
  10.10*) TARGET=darwin14; X86_64H_SUPPORTED=1; I386_SUPPORTED=1; NEED_TAPI_SUPPORT=0; OSX_VERSION_MIN_INT=10.5;  ;;
  10.11*) TARGET=darwin15; X86_64H_SUPPORTED=1; I386_SUPPORTED=1; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.5;  ;;
  10.12*) TARGET=darwin16; X86_64H_SUPPORTED=1; I386_SUPPORTED=1; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.5;  ;;
  10.13*) TARGET=darwin17; X86_64H_SUPPORTED=1; I386_SUPPORTED=1; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.5;  ;;
  10.14*) TARGET=darwin18; X86_64H_SUPPORTED=1; I386_SUPPORTED=0; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9;  ;;
  10.15*) TARGET=darwin19; X86_64H_SUPPORTED=1; I386_SUPPORTED=0; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9;  ;;
*) echo "Unsupported SDK"; exit 1 ;;
esac

case $SDK_VERSION in
  10.6*)   TARGET=darwin10;   SUPPORTED_ARCHS="i386 x86_64"; NEED_TAPI_SUPPORT=0; OSX_VERSION_MIN_INT=10.6 ;;
  10.7*)   TARGET=darwin11;   SUPPORTED_ARCHS="i386 x86_64"; NEED_TAPI_SUPPORT=0; OSX_VERSION_MIN_INT=10.6 ;;
  10.8*)   TARGET=darwin12;   SUPPORTED_ARCHS="i386 x86_64 x86_64h"; NEED_TAPI_SUPPORT=0; OSX_VERSION_MIN_INT=10.6 ;;
  10.9*)   TARGET=darwin13;   SUPPORTED_ARCHS="i386 x86_64 x86_64h"; NEED_TAPI_SUPPORT=0; OSX_VERSION_MIN_INT=10.6 ;;
  10.10*)  TARGET=darwin14;   SUPPORTED_ARCHS="i386 x86_64 x86_64h"; NEED_TAPI_SUPPORT=0; OSX_VERSION_MIN_INT=10.6 ;;
  10.11*)  TARGET=darwin15;   SUPPORTED_ARCHS="i386 x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.6 ;;
  10.12*)  TARGET=darwin16;   SUPPORTED_ARCHS="i386 x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.6 ;;
  10.13*)  TARGET=darwin17;   SUPPORTED_ARCHS="i386 x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.6 ;;
  10.14*)  TARGET=darwin18;   SUPPORTED_ARCHS="x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  10.15*)  TARGET=darwin19;   SUPPORTED_ARCHS="x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  10.16*)  TARGET=darwin20;   SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  11|11.0*) TARGET=darwin20.1; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  11.1*)   TARGET=darwin20.2; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  11.2*)   TARGET=darwin20.3; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  11.3*)   TARGET=darwin20.4; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  12|12.0*) TARGET=darwin21.1; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  12.1*)   TARGET=darwin21.2; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  12.2*)   TARGET=darwin21.3; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  12.3*)   TARGET=darwin21.4; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  12.4*)   TARGET=darwin21.5; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  13|13.0*) TARGET=darwin22.1; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  13.1*)   TARGET=darwin22.2; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  13.2*)   TARGET=darwin22.3; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  13.3*)   TARGET=darwin22.4; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.9 ;;
  14|14.0*) TARGET=darwin23;   SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  14.1*)   TARGET=darwin23.1; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  14.2*)   TARGET=darwin23.2; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  14.3*)   TARGET=darwin23.3; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  14.4*)   TARGET=darwin23.4; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  14.5*)   TARGET=darwin23.5; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  14.6*)   TARGET=darwin23.6; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  15|15.0*) TARGET=darwin24;   SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  15.1*)   TARGET=darwin24.1; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  15.2*)   TARGET=darwin24.2; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  15.3*)   TARGET=darwin24.3; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  15.4*)   TARGET=darwin24.4; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  15.5*)   TARGET=darwin24.5; SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  26|26.0*) TARGET=darwin25;   SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  26.1*) TARGET=darwin25.1;   SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  26.2*) TARGET=darwin25.2;   SUPPORTED_ARCHS="arm64 arm64e x86_64 x86_64h"; NEED_TAPI_SUPPORT=1; OSX_VERSION_MIN_INT=10.13 ;;
  *) echo "Unsupported SDK"; exit 1 ;;
esac

• darwin17(MacOSX 10.13相当)
SDKのバージョンは 10.13 ですので、これは基本的にはMacOSX 10.13 上で動作するバイナリを作ることを目的としたものです。 ただし「OSX_VERSION_MIN_INT=10.6」という記述がありますので、 MacOSX 10.6 以降であれば、MacOSX 10.13よりも古いMacOSX上でも動作可能なバイナリが生成されると考えられます。


よく見るとosxcross バージョン1.1におけるbuild.sh では、 darwin17(MacOSX 10.13相当)の行で「OSX_VERSION_MIN_INT=10.5」と記述されており、 osxcross バージョン1.5におけるbuild.sh の記述と食い違っています。 この記事では両者の積集合をとって「OSX_VERSION_MIN_INT=10.6」と解釈することに致します。


• darwin18(MacOSX 10.14相当)
「OSX_VERSION_MIN_INT=10.9」となっており、darwin17と比べて値がいっきに増えています。 そのため、より広範囲の（古いバージョンの）MacOSXにまで対応したい場合、 darwin18 は darwin17より不利ということになります （さらに言えば、darwin18(MacOSX 10.14相当)以降はi386（x86版）のサポートが打ち切られています）。 darwin12、darwin17、darwin18の三つから（なるべく古いMacOSXにも対応するように）なるべく新しいSDKを選ぶと、 おそらくx64版を作る場合はdarwin17（MacOSX 10.13）を選ぶのが最適であろうと判断できます （さらに言えば、現在入手可能なPureDarwinもdarwin17相当です）。


• darwin20(MacOSX 10.16相当)
arm64のサポートが追加されています （さらに言えば、これ以降、SUPPORTED_ARCHSの値は一定です）。 しかもOSX_VERSION_MIN_INTの値はdarwin18と同じく10.9のまま変わりません。 arm64のサポートを重視するならこれを選択するのがよいのでしょう。

• x86/x64版をビルドする場合 : darwin17(MacOSX 10.13相当) を選ぶものとする
• arm64版をビルドする場合 : darwin20(MacOSX 10.16相当) を選ぶものとする

MacOSX SDKの入手

• phracker版(25MB)： https://github.com/phracker/MacOSX-SDKs/releases/download/11.3/MacOSX10.13.sdk.tar.xz
• joseluisq版(34MB)：https://github.com/joseluisq/macosx-sdks/releases/download/10.13/MacOSX10.13.sdk.tar.xz

• phracker版(48MB)： https://github.com/phracker/MacOSX-SDKs/releases/download/11.3/MacOSX11.1.sdk.tar.xz
• joseluisq版(54MB)：https://github.com/joseluisq/macosx-sdks/releases/download/11.1/MacOSX11.1.sdk.tar.xz

llvm_clangの入手

/****************************** v0.15 ********************************/

Changed:
 * Updated cctools to 895
 * Updated ld64 to 274.2 (without TAPIv2 support)

Added:
 * Support for ThinLTO:
   -> https://clang.llvm.org/docs/ThinLTO.html
   -> http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html
   -> Requires LLVM/Clang >= 3.8. LLVM/Clang >= 3.9 is recommended.
 * USE_CLANG_AS build.sh option:
   -> Use Clang as assembler.

clang --version

• Clang for x86_64 Ubuntu 16.04(164MB)：https://releases.llvm.org/3.9.0/clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz

cd $HOME/Downloads
tar xvf clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz
mv clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04 llvm_clang_install_dir

cd $HOME/Downloads/llvm_clang_install_dir
cd bin
./clang

./clang: error while loading shared libraries: libtinfo.so.5: Cannot open shared object file: No such file or directory

ln -s /usr/lib64/libncursesw.so libtinfo.so.5
ls -al

env LD_LIBRARY_PATH=. ./clang

export LD_LIBRARY_PATH=$HOME/Downloads/llvm_clang_install_dir/bin:$LD_LIBRARY_PATH

export PATH=$HOME/Downloads/llvm_clang_install_dir:$PATH

export LD_LIBRARY_PATH=$HOME/Downloads/llvm_clang_install_dir/bin:$LD_LIBRARY_PATH
export PATH=$HOME/Downloads/llvm_clang_install_dir:$PATH

osxcross本体（？）の入手

• xar
公式サイトはhttps://github.com/tpoechtrager/xarになります。 ここから xar を入手します。

画面上方の真ん中よりやや右にある「Code」と書かれた緑色のボタンを押すと、 「Download ZIP」と表示されたプルダウンメニューが出るはずです。 このメニューから「Download ZIP」を選びます。 xar-master.zip という名前のファイルをダウンロードすることができますが、 これが xar の本体です。

尚、xarに限って言えば、そのバージョンを気にする必要はありません。 下二つに比べればこれはザコキャラです。


• apple-libtapi
公式サイトはhttps://github.com/tpoechtrager/apple-libtapiになります。 ここから apple-libtapi を入手します。

ただし入手するバージョンに細心の注意を払ってください！ 残念ながら今回に関しては、単純に新しければよいというものでもありません。

darwin17 のコースで行く場合、1000.10.8を使います（これ以外は不可と考えるくらいでよいです）。 画面左上に「1600.0.11.8」などと書かれたボタンがあると思います（ただし新しいバージョンに更新された場合はこの表示が異なるかもしれません）。 これを押すと「Switch branches/tags」というタイトルのプルダウンメニューが出るはずです。

このメニューから「1000.10.8」を選ぶと、先ほどのボタンの名前が「1000.10.8」という名前に変わります （そもそもページ自体が新しいものに遷移し、URL文字列の最後もこのバージョンのものに変化しているはずです）。

画面上方の真ん中よりやや右にある「Code」と書かれた緑色のボタンを押すと、 「Download ZIP」と表示されたプルダウンメニューが出るはずです。 このメニューから「Download ZIP」を選びます。 apple-libtapi-1000.10.8.zip という名前のファイルをダウンロードすることができますが、 これが apple-libtapi（Ver1000.10.8）の本体です。


• cctools-port
公式サイトはhttps://github.com/tpoechtrager/cctools-portになります。 ここから cctools-port を入手します。

ただし入手するバージョンに細心の注意を払ってください！ 残念ながら今回に関しては、単純に新しければよいというものでもありません。

darwin17 のコースで行く場合、927.0.2-ld64-450.3を使います（これ以外は不可と考えるくらいでよいです）。 画面左上に「1030.6.3-ld64-956.6」などと書かれたボタンがあると思います（ただし新しいバージョンに更新された場合はこの表示が異なるかもしれません）。 これを押すと「Switch branches/tags」というタイトルのプルダウンメニューが出るはずです。

このメニューから「927.0.2-ld64-450.3」を選ぶと、先ほどのボタンの名前が「927.0.2-ld64-450.3」という名前に変わります （そもそもページ自体が新しいものに遷移し、URL文字列の最後もこのバージョンのものに変化しているはずです）。

画面上方の真ん中よりやや右にある「Code」と書かれた緑色のボタンを押すと、 「Download ZIP」と表示されたプルダウンメニューが出るはずです。 このメニューから「Download ZIP」を選びます。 cctools-port-927.0.2-ld64-450.3.zip という名前のファイルをダウンロードすることができますが、 これが cctools-port（cctools Ver 927.0.2 および ld64 Ver 450.3）の本体です。

## Apple TAPI Library ##

if [ $NEED_TAPI_SUPPORT -eq 1 ]; then
  get_sources https://github.com/tpoechtrager/apple-libtapi.git 1000.10.8

  if [ $f_res -eq 1 ]; then
    pushd $CURRENT_BUILD_PROJECT_NAME &>/dev/null
    INSTALLPREFIX=$TARGET_DIR ./build.sh
    ./install.sh
    popd &>/dev/null
    build_success
  fi
fi

## cctools and ld64 ##

CCTOOLS_VERSION=927.0.2
LINKER_VERSION=450.3

get_sources \
  https://github.com/tpoechtrager/cctools-port.git \
  $CCTOOLS_VERSION-ld64-$LINKER_VERSION

xarのビルド

1. xar-master.zip を解凍し、ディレクトリ xar-master に展開します。

zip ファイルの解凍には以下のように unzip コマンドを用います。



unzip xar-master.zip



環境によっては unzip コマンドがインストールされていないかもしれません。 その場合は素直に unzip コマンドをインストールするか、7z コマンドなど、 zipを解凍できる他のコマンドがある場合はそれを使ってください。 例えば 7z コマンドで解凍する場合は以下のようになります。


7z x xar-master.zip


もしかすると unzip ではなく unzzip という名前のコマンドがインストールされているかもしれません。 しかしこの unzzip を使うのは避けた方がよいでしょう。 通常のファイルがディレクトリとして展開されるなどおかしな動作をする場合があります。
2. ディレクトリ mkfalt_xar 内に入り、シェルスクリプト make_world.sh を以下のように実行します。



THIS_PROJ_DIR=../xar-master sh make_world.sh install



この make_world.sh では xar.mak（GNU Makefileです）を内部で実行します。 すなわち「make -f xar.mak install」に相当するコマンドを実行します （このシェルスクリプトの最後に辺りに書かれているはずです）。

これを実行すると、ディレクトリ mkfalt_xar の直下にディレクトリ out_dir が自動的に作られますが、 ビルドの結果生成されるオブジェクトファイルやライブラリ、実行バイナリなどは、この out_dir ディレクトリ配下に一時的に置かれます。 またinstall時にこれらのうち必要なものが ../install_dir へコピーされます。

インストール先はデフォルトで ../install_dir となっていますが、 これを変更したい場合は、環境変数 THIS_INSTALL_DIR で指定を行ってください。 例えば「../../install_dir」に変更したければ以下の通りです。


THIS_PROJ_DIR=../xar-master THIS_INSTALL_DIR=../../install_dir sh make_world.sh install

あるいは「$HOME/Downloads/install_dir」に変更したければ以下の通りです。


THIS_PROJ_DIR=../xar-master THIS_INSTALL_DIR=$HOME/Downloads/install_dir sh make_world.sh install

ただし、インストール先を変える場合は、xar、apple-libtapi、cctools-port で同じインストール先に揃えるようにしてください。


この先で使う mkfalt_cctools-port に含まれる Makefile では xar や apple-libtapi でインストールしたライブラリを使用します。 mkfalt_cctools-port の Makefile では、自分のインストール先と同じ場所に これらのライブラリが置かれているとみなします。 よって、自分のインストール先とこれらのライブラリの置かれた場所が異なる場合、 インクルードヘッダが検出できずにコンパイルエラーが発生するか、 あるいはライブラリ本体を検出できずリンクエラーが発生することになります。
インストールの結果、xar、apple-libtapi、cctools-port のそれぞれが どのようにインストールされるかを個別に解析する目的に限りますが、 敢えてそれぞれのインストール先を別々にすることもできます。 ただしこれはあくまで解析目的での話です。
依存ライブラリの位置を引数として指定できるような柔軟性をMakefileに持たせることも可能でしたが、 さすがに指定が煩雑になりすぎると思われたのでそのような仕様にはしていません。 仮にそのようなことがしたい場合、Makefileを直接修正するなどしてください。 このMakefileの可読性は比較的高く、さほど余計なこともしていないので改造は容易だと思います。

この xar.mak は今ビルドしようとしているプロジェクトの外からでも実行することができるようになっています。 ただしその場合、そのプロジェクトのディレクトリの場所がどこかをこのMakefileに教える必要があり、 その場所を指示しているのが上記の「THIS_PROJ_DIR=../xar-master」の部分になります。

尚、多くのMakefileがそうであるように、この xar.mak もプロジェクトの中に置いて実行することも可能です。 まずディレクトリ mkfalt_xar をまるごと xar-master の直下に置き、 xar-master/mkfalt_xar に移動した後に xar.mak を実行します。 コマンドにすれば以下のような形になるでしょう。


cp -r mkfalt_xar xar-master/
cd xar-master/mkfalt_xar
make -f xar.mak install

この場合は、環境変数 THIS_PROJ_DIR の指定を省略できます（「THIS_PROJ_DIR=..」が指定されたのと同じです）。

問題なく完了した場合、一つ上のディレクトリに install_dir という名前のディレクトリが作られ、 その直下にディレクトリ include、ディレクトリ lib、ディレクトリ bin などが作られているはずです。 さらにディレクトリ include 直下にはディレクトリ xar が、 ディレクトリ lib 直下には動的ライブラリ libxar.so などが格納されているはずです。 列挙すると以下のような感じです（他にもシンボリックリンクなどのファイルが少しありますが、 とりあえず以下が確認できればよいでしょう）。



install_dir/include/xar/xar.h
install_dir/lib/libxar.so
install_dir/lib/libxar.a
install_dir/bin/xar


おめでとうございます！ これでまずは xar のインストールが完了しました。 しかしながらここまではただのウォーミングアップです。 ここから先が本番（ボスキャラ）となります。

この先にいる相手は、残念ながら xar のように易しくはありませんが、 まずはこの xar のビルドをチュートリアルとしてしっかり押えておきましょう。 この先も基本的には、xar と同じやり方でのビルドになるからです。

apple-libtapiのビルド

1. apple-libtapi-1000.10.8.zip を解凍し、ディレクトリ apple-libtapi-1000.10.8 に展開します。



unzip apple-libtapi-1000.10.8.zip



展開ディレクトリの名前 apple-libtapi-1000.10.8 が長いと思われるなら、 この名前を変更しても構いません。 その場合、以下の説明で apple-libtapi-1000.10.8 の部分をその名前に読み替えてください。


2. ディレクトリ mkfalt_apple-libtapi 内に入り、シェルスクリプト make_world.sh を以下のように実行します。



THIS_PROJ_DIR=../apple-libtapi-1000.10.8 sh make_world.sh install


「まずは一旦ビルドできるかどうかを確認すべきで、インストールなど後回しだ」と思われる方は 以下のように二段階で実行してください。



THIS_PROJ_DIR=../apple-libtapi-1000.10.8 sh make_world.sh
THIS_PROJ_DIR=../apple-libtapi-1000.10.8 sh make_world.sh install



ディレクトリ mkfalt_apple-libtapi 内には、実に18個ものMakefile（すべてGNU Makefileです）があり、 make_world.sh においては、特に余計な分岐はなく単純に以下の順番でこれを実行します （ただし途中でエラーが発生した場合はそこで停止するようにはしてあります）。


make -f LLVMSupport.mak
make -f LLVMDemangle.mak
make -f LLVMBinaryFormat.mak
make -f LLVMTableGen.mak
make -f clang-tblgen.mak
make -f Basic.mak
make -f clangBasic.mak
make -f llvm-tblgen.mak
make -f llvm_IR.mak
make -f LLVMBitReader.mak
make -f LLVMObject.mak
make -f AttributesCompatFunc.mak
make -f LLVMCore.mak
make -f LLVMMC.mak
make -f LLVMMCParser.mak
make -f AST.mak
make -f tapiCore.mak
make -f libtapi.mak

xar.mak と同じく、これらの Makefile も apple-libtapi を外部からビルドすることができます。 そのため、今回も THIS_PROJ_DIR で apple-libtapi が展開されたディレクトリを指定しています。


make_world.sh による実行では全体をいくつかのフェーズに分けており、 それぞれのフェーズの開始時にコンパイルオプションなどの情報を提示しつつ一時停止します。 そこで続行するか否かの確認メッセージも出ますので、 ゆっくりと提示された情報を読み、準備がよければEnterキーなど何かキーを押して開始してください。

この一時停止が不要な場合は make_world.sh の替わりに make_world_yes.sh を使うこともできますが、 初めての場合は、make_world.sh での実行をお勧めします。

上記を見て何か気づかれたでしょうか？ ほとんどの Makefile の名前の先頭が LLVM で始まっています。 また途中で clang-tblgen.mak や clangBasic.mak といった名前のMakefileも見られます。

今我々は libtapi と呼ばれるライブラリをビルドしようとしていたはずですが、 これではまるで llvm_clang をビルドしているかのようです。 実際その通りで、実は libtapi に含まれるほとんどのファイルは llvm_clang のソースコードです。 llvm_clang は巨大なコンパイラシステムで、そのソースコードも当然巨大なものですが、 libtapi のビルドの難しさは、実のところほぼ llvm_clang のビルドの難しさに起因しています。


というわけで、llvm_clang のソースコードをビルドした経験を何度もお持ちの方（あまりいないとは思いますが）は、 このミッションはさほど難しく感じないかもしれません。 逆にこれから llvm_clang のソースコードのビルドに挑戦しようとお考えの方（こちらもあまりいないとは思いますが）は、 今回のミッションはよい練習になると思います。

これらのすべてを詳細に把握しておく必要はありませんが、 「何をやっているのか」「何のためにそれをやっているのか」「それが後でどう使われるのか」などの大まかな流れというか依存関係は把握しておく方がよいでしょう。 その方が万一エラーが発生した場合でも見通しがよくなります。 「困難は分割せよ」が鉄則です。


• LLVMSupport.mak

libLLVMSupport.a という静的ライブラリをビルドします。 これはいわゆる基本的なユーティリティの寄せ集めで、 ビルド中のC++ファイル名からもその働きがおおよそ推察できます （例えば MD5.cpp などはMD5を計算するものでしょう）。

基本的ということは、役割としては一つ前にビルドした xar に近く、 一番初めの方でビルドしておくべきライブラリということです （znk_projectで言えばlibZnkのようなライブラリに相当します）。

ただし xar とは異なり、libLLVMSupport は他のライブラリに特には依存していません （一方の xar では liblzma、libbz2、libcrypt、libacl、libxml などを使用しており、 それらに依存しています）。


• LLVMDemangle.mak

libLLVMDemangle.a という静的ライブラリをビルドします。

Demangle（デマングル）というのは、（C++の世界においては）リンク時に参照する関数名などの変換処理を意味しています。 C++をご存知の方は解説不要でしょうし、C++をご存知でない方もまた知る必要のない情報です。 このライブラリのビルドはすぐに終わります。


• LLVMBinaryFormat.mak

libLLVMBinaryFormat.a という静的ライブラリをビルドします。

名前からBinaryファイルを扱うためのライブラリと推察できますが、 これだけだと抽象的すぎて何がなんやらわからないと思いますが、 Dwarf.cpp という名前のファイルがあることはわかります。

DWARF（ドワーフ）とは、一般にはファンタジーに現れる小人で、DQ3ではバーンの抜け道で旅人に嫌がらせ デバッグ用のファイル形式の名前です。 適当に流しておきましょう。 このライブラリのビルドはすぐに終わります。


• LLVMTableGen.mak

libLLVMTableGen.a という静的ライブラリをビルドします。

第四形態です。 デスピサロと同じくこの形態あたりから攻撃がきつくなってきます。

何をするものなのか非常に説明しにくいですが、 「C++のヘッダファイルを自動生成するツール」をビルドするための下請けライブラリです。

何を言ってるのかよくわからないかもしれませんが、 このすぐ後に登場するclang-tblgenというツールをビルドするための材料という理解で結構です。


• clang-tblgen.mak

clang-tblgenというツールの実行バイナリをビルドします。

このツールは、拡張子が td となっているファイルを、拡張子が inc となっているファイルに変換するためのツールです。 ただしこの拡張子に大して意味はなく、 inc ファイルに至っては、その実体はただの C++ のヘッダファイルです。 こんなものをいつ使うかと思われるかもしれませんが、今でしょ！次に使います。


• Basic.mak

ディレクトリ src/llvm/projects/clang/include/clang/Basic にまとめられた td ファイルを inc ファイルに変換するための Makefile で、 この Makefile においては C/C++コンパイラではなく、直前に作った clang-tblgen というツールで変換を行います。 これらの inc ファイルは mkfalt_apple-libtapi 内の auto_hdr/clang-tbl/clang_Basic/clang/Basic へ生成されます。

これから先のビルドにあたってこの inc ファイル（ヘッダファイル）をインクルードするソースファイルが登場しますので、 このタイミングで inc ファイルを作っておかなければなりません。


• clangBasic.mak

libclangBasic.a という静的ライブラリをビルドします。

いわゆる llvm_clang コンパイラの基本となるライブラリです。 なぜ libtapi のビルドに（リンカならともかく）コンパイラの方の基本モジュールが必要なのか段々とよくわからなくなってくると思いますが、 とにかくこれが必要なのでしょう。

このライブラリはかなりの強敵で、直前のBasicで適切にincファイル（ヘッダファイル）を生成していないと コンパイルに失敗してしまいます。 これらに対するインクルードパスは -I auto_hdr/clang-tbl/clang_Basic となります。


• llvm-tblgen.mak

llvm-tblgenというツールの実行バイナリをビルドします。

このツールは、拡張子が td となっているファイルを、拡張子が inc または gen となっているファイルに変換するためのツールです。 ただしこの拡張子に大して意味はなく、 inc と gen ファイルに至っては、その実体はただの C++ のヘッダファイルです。 こんなものをいつ使うかと思われるかもしれませんが、今でしょ！次に使います。


clang-tblgen のときとほぼ同じ説明で一体何が違うのか甚だ疑問ですが、 拡張子をよくご覧下さい。 こちらは inc の他に gen という拡張子のファイルも生成します（ちなみにどちらも実体はC+++のヘッダファイルです）。 なぜわざわざ拡張子を別にしているのかその真意は不明ですが、 中身を見た感じでは、gen ファイルの方は人間が直接書くにはあまりに困難なデータ列が大量に生成されています （おそらく何かのデータテーブルでしょう）。

またその名前から、clang-tblgen では clang コマンド関係のヘッダを生成する一方、 llvm-tblgen では llvm 関係（とりあえず clang コマンド以外のシステムの部分と考えましょう）のヘッダを生成するということなのでしょう。


• llvm_IR.mak

ディレクトリ src/llvm/include/llvm/IR にある Attribute.td と Intrinsics.td を gen ファイルに変換するための Makefile で、 この Makefile においては C/C++コンパイラではなく、直前に作った llvm-tblgen というツールで変換を行います。 これらの gen ファイルは mkfalt_apple-libtapi 内の auto_hdr/llvm-tbl/llvm_IR へ生成されます。

これから先のビルドにあたってこの gen ファイル（ヘッダファイル）をインクルードするソースファイルが登場しますので、 このタイミングで gen ファイルを作っておかなければなりません。


• LLVMBitReader.mak

libLLVMBitReader.a という静的ライブラリをビルドします。

名前だけだと libLLVMBinaryFormat と似ており何が違うのかよくわからない感じですが、 構成ファイルの名前も MetadataLoader.cpp など抽象的でよくわからない感じです。 適当に流しておきましょう。 このライブラリのビルドはすぐに終わります。

…と言いたいところですが、このライブラリは実は強敵です。 直前のllvm_IRで適切にgenファイル（ヘッダファイル）を生成していないと コンパイルに失敗してしまいます。 これらに対するインクルードパスは -I auto_hdr/llvm-tbl/llvm_IR となります。


• LLVMObject.mak

libLLVMObject.a という静的ライブラリをビルドします。

Object と付いていますが、いわゆるObject指向プログラミングの意味での Object ではなく、 コンパイラが生成するオブジェクトファイルのことを意味しているのだと思われます。 実際、構成ファイルも COFFObjectFile.cpp や ELFObjectFile.cpp、MachOObjectFile.cpp などといった名前となっています。

このライブラリも LLVMBitReader と同じく、ビルドにはllvm_IRで生成したgenファイルが必要です。


• AttributesCompatFunc.mak

ディレクトリ src/llvm/lib/IR にある AttributesCompatFunc.td を inc ファイルに変換するための Makefile です。 この Makefile においては C/C++コンパイラではなく、llvm-tblgen で変換を行います。 AttributesCompatFunc.inc ファイルは mkfalt_apple-libtapi 内の auto_hdr/llvm-tbl/AttributesCompatFunc へ生成されます。

これから先のビルドにあたってこの inc ファイルをインクルードするソースファイルが登場しますので、 このタイミングで作っておかなければなりません。


• LLVMCore.mak

libLLVMCore.a という静的ライブラリをビルドします。

名前からしてLLVMの心臓部なのでしょうか？

このライブラリも LLVMBitReader と同じく、ビルドにはllvm_IRで生成したgenファイルが必要です。 また直前で生成したAttributesCompatFunc.incも必要になります。 これらに対するインクルードパスは -I auto_hdr/llvm-tbl/llvm_IR -I auto_hdr/llvm-tbl/AttributesCompatFunc となります。


• LLVMMC.mak

libLLVMMC.a という静的ライブラリをビルドします。

このMCが何を意味しているのかいまいち不明ですが、LLVM に llvm-mc（LLVM Machine Code）というコマンドがあるようなので 多分それに関するライブラリなのでしょう。 アセンブラに関係する処理だと思います。

尚、LLVMCoreとは異なり、inc ファイルや gen ファイルなども不要なので、 このライブラリは割とすんなりビルドできるでしょう。


• LLVMMCParser.mak

libLLVMMCParser.a という静的ライブラリをビルドします。

LLVMMCがアセンブラに関係しているライブラリと思われますので、 このライブラリはそのパーザ処理に相当することをしているのでしょう。 LLVMCoreと同様、特に何かに依存していることもないため、すんなりとビルドできるでしょう。


• AST.mak

ディレクトリ src/llvm/projects/clang/include/clang/AST にまとめられた td ファイルを inc ファイルに変換するための Makefile です。 この Makefile においては C/C++コンパイラではなく、llvm-tblgen で変換を行います。 これらの inc ファイルは mkfalt_apple-libtapi 内の auto_hdr/clang-tbl/clang_AST/clang/AST へ生成されます。

これから先のビルドにあたってこれらの inc ファイルをインクルードするソースファイルが登場しますので、 このタイミングで作っておかなければなりません。


• tapiCore.mak

libtapiCore.a という静的ライブラリをビルドします。

さていよいよ大詰めです。 ようやくlibtapi本体関連のビルドとなります。 JSONFile.cpp や YAML.cpp という名前のファイルが見られることから、 tbl ファイル（TAPIを構成するファイル）とは json あるいは yaml に関係したフォーマットではないかと推察されます。

このライブラリのビルドでは Basic.mak と AST.mak において作った inc ファイルが必要となります。 これらに対するインクルードパスは -I auto_hdr/clang-tbl/clang_Basic -I auto_hdr/clang-tbl/clang_AST となります。


• libtapi.mak

libtapi.so.6.0.1 という動的ライブラリをビルドします。

長かったですがようやくラストです（apple-libtapiについてのですが）。 ここでビルドするC++のファイルは少ないです。 しかし最後にここまでビルドしてきた静的ライブラリすべてをリンクするという まさしくこれまでの集大成となる処理を行います。

リンクされる静的ライブラリは10個です。 すなわち、libtapiCore.a libclangBasic.a libLLVMObject.a libLLVMBitReader.a libLLVMCore.a libLLVMMCParser.a libLLVMMC.a libLLVMBinaryFormat.a libLLVMSupport.a libLLVMDemangle.a となります。

敢えて作成順とほぼ逆順に書きましたが、リンクにおいては 基本的なものほど後ろに持ってくる必要があるため、そのようにしています （libLLVMTableGen.a がありませんが、これについては clang-tblgen と llvm-tblgen のビルドにおいてリンクされており、 既に役目を終えています）。

またこのMakefileでは、作成した動的ライブラリ libtapi.so.6.0.1 とヘッダファイル （tapi.hを始めとした七つの h ファイルとVersion.incファイル）がインストールされます。 また同時に、libtapi.so.6.0.1 へのシンボリックリンクとして libtapi.so.6 と libtapi.so が作成されます。

make_world.sh の引数に install を指定した場合、 他のMakefileでは単にビルドのみが行われますが、 この libtapi.mak についてはビルドとインストールの両方が行われます。


3. 問題なく完了した場合、一つ上のディレクトリに install_dir という名前のディレクトリが作られ、 そこにすべてがインストールされます。

ディレクトリ install_dir の直下には、ディレクトリ include、ディレクトリ lib、ディレクトリ bin などが作られているはずです。 さらにディレクトリ include 直下にはディレクトリ tapi が、 ディレクトリ lib 直下には動的ライブラリ libtapi.so などが格納されているはずです。 列挙すると以下のような感じです（他にもシンボリックリンクなどのファイルが少しありますが、 とりあえず以下が確認できればよいでしょう）。



install_dir/include/tapi/APIVersion.h
install_dir/include/tapi/Defines.h
install_dir/include/tapi/LinkerInterfaceFile.h
install_dir/include/tapi/PackedVersion32.h
install_dir/include/tapi/Symbol.h
install_dir/include/tapi/Version.h
install_dir/include/tapi/Version.inc
install_dir/include/tapi/tapi.h
install_dir/lib/libtapi.so.6.0.1
install_dir/lib/libtapi.so.6
install_dir/lib/libtapi.so


長い戦いでしたが、最終的にインストールされるファイルは割とあっさりしています。


この先、展開ディレクトリ apple-libtapi-1000.10.8 は使いませんので、 ビルドしたライブラリ（libtapi.so.6.0.1）には絶対に何の問題もないという確固たる自信があるだとか、 ディスクサイズの残りのサイズが切迫しておりやむを得ない状況であるならば このタイミングでこの展開ディレクトリを削除することもできます （展開ディレクトリは約460MBもあるので割とバカにならないサイズです）。

また、mkfalt_apple-libtapi/out_dir 内にあるファイル（こちらは60MB程度になっていると思います）についても ビルドのために一時的に作られたファイルですので削除が可能です。 ディレクトリ out_dir ごと削除してもよいですし、 「sh make_world.sh clean」を実行することでも out_dir の中身が削除されます。

ただし繰り返しになりますが、削除を行うのはビルドの成功に絶対の自信があるだとか、 ディスクサイズの残りのサイズが切迫している場合だけにしておいた方がよいでしょう。 全部削除してしまうと、後で何か問題があった場合に「部分的な再ビルド」ができなくなる（ゼロから全ビルドをやり直し）になります。 特に apple-libtapi の場合、ゼロから全ビルドをやり直すとまた25分もの時間が掛かることになります。

尚、当然ですがインストールディレクトリ（install_dir）の方はこの先もまだ使いますので削除してはいけません。

お疲れ様でした。 これで libtapi のインストールが完了です。 次はいよいよラスボス、リンカld64のビルドです。

cctools-portのビルド

1. cctools-port-927.0.2-ld64-450.3.zip を解凍し、ディレクトリ cctools-port-927.0.2-ld64-450.3 に展開します。



unzip cctools-port-927.0.2-ld64-450.3.zip



展開ディレクトリの名前 cctools-port-927.0.2-ld64-450.3 が長いと思われるなら、 この名前を変更しても構いません。 その場合、以下の説明で cctools-port-927.0.2-ld64.450.3 の部分をその名前に読み替えてください。


2. ディレクトリ mkfalt_cctools-port 内に入り、シェルスクリプト make_world.sh を以下のように実行します。



THIS_PROJ_DIR=../cctools-port-927.0.2-ld64-450.3 sh make_world.sh install


「まずは一旦ビルドできるかどうかを確認すべきで、インストールなど後回しだ」と思われる方は 以下のように二段階で実行してください。



THIS_PROJ_DIR=../cctools-port-927.0.2-ld64-450.3 sh make_world.sh
THIS_PROJ_DIR=../cctools-port-927.0.2-ld64-450.3 sh make_world.sh install



ディレクトリ mkfalt_cctools-port 内には、実に17個ものMakefile（すべてGNU Makefileです）があり、 make_world.sh においては、特に余計な分岐はなく単純に以下の順番でこれを実行します （ただし途中でエラーが発生した場合はそこで停止するようにはしてあります）。


make -f libobjc.mak
make -f libstuff.mak
make -f ar.mak
make -f as-arm.mak
make -f as-i386.mak
make -f as-x86_64.mak
make -f as-ppc.mak
make -f as-ppc64.mak
make -f as.mak
make -f misc.mak
make -f otool.mak
make -f ld64-libBlocksRuntime.mak
make -f ld64-libhelper.mak
make -f ld64-libParsers.mak
make -f ld64-libPasses.mak
make -f ld64-ld.mak
make -f ld64-other.mak

xar.mak と同じく、これらの Makefile は cctools-port の展開ディレクトリの外部からビルドすることができます。 そのため、今回も同じく THIS_PROJ_DIR で cctools-port の展開ディレクトリの位置を指定しています。


make_world.sh の引数として install を指定した場合、 正確には上記のMakefileに加え、最後に man 関係のファイルのインストールのために install_man.sh が実行されます。 このシェルスクリプトは単に man 関係のファイルをディレクトリ install_dir/share 配下にコピーするものになります。
cctools-port の場合、apple-libtapi とは異なり、 オリジナルの状態でも cmake とやらは使われておらず、いわゆる GNU のconfigure スクリプトを実行した上でmakeをするという 一般的な構成になっています。 よってこれについては「単にそれを実行してください」で済ませてもよかったのですが、 xar、apple-libtapi、cctools-port のすべてにおいてビルド方法に統一性をもたせるため、 cctools-port についても他と同様のMakefileを用意してあります。

前半では ar（ライブラリアン）など、各種ツールをビルドします。 後半では ld64 の本体をビルドします。 それぞれのMakefileについて概要を以下に説明しましょう。


• libobjc.mak

libobjc.a という静的ライブラリをビルドします。

ここでの objc とはプログラミング言語 Objective C のことです。 Objective C は、C++などと同じくC言語を拡張したような言語で、 MacOSXの世界で使用されることが多いです。 そもそもcctools-port はMacOSX用のツールを集めたものですから、ここで Objective C も登場するのでしょう。

cctools-port の中では一番基本的なライブラリで他のライブラリに特には依存していません。 そのため一番最初にビルドします。

C言語のソースコードであるため、ビルドも比較的高速ですぐに終わります。


• libstuff.mak

libstuff.a という静的ライブラリをビルドします。

英語で「stuff」とは「もの」という意味ですね。 読み方は多分「リブスタッフ」ですね。

live staff


違う！ソイツじゃない！

というかデススタッフ（death staff）だ！おまえは！

確かに「live」と「death」で少し関係しており…いや「live」ではなく「lib」だ！


あと事務所のスタッフ（staff）とも関係ありません。
Close


「もの」とはあまりに漠然とした名前過ぎてて何が何やらわかりませんが、 ライブラリの名前とはそんなものかもしれません。


znk_projectのライブラリの名前だって冷静に見れば意味がわかりませんからね （libZnkとかlibMoaiとか…）。

構成ファイルの名前（dylib_root.c ofile.c symbol_list.c など）から考えると、 おそらくMacOSX関係のライブラリやオブジェクトファイルの基本的な取り扱いに関するユーティリティをまとめたものだと思われます。

C言語のソースコードであるため、ビルドも比較的高速ですぐに終わります。


• ar.mak

ar （ライブラリアン）をビルドします。

ここに来てようやくar（ライブラリアン）が登場です。

ar（ライブラリアン）とは（C言語/C++の文脈では）静的ライブラリを作るためのツールです。 いえ、今までも散々静的ライブラリとやらを作ってきたではないかと思われるかもしれませんが、 これはllvm付属のar（ないしはLinux標準に備わったar）を使って作っていたものになります。 一方、これから作る ar はMacOSX（Darwin）用の ar ということになります （ただしLinux上で動作します。ややこしい！）。

tarというコマンドをご存知かもしれませんがあれとやっていることは本質的に同じで、 静的ライブラリとは複数のオブジェクトファイルを一つのアーカイブ（ARchive）ファイルにまとめたものに他なりません。

C言語のソースコードであるため、ビルドも比較的高速ですぐに終わります。 このツールのビルドでは、最後にライブラリとして libstuff.a がリンクされます。


上で「MacOSX（Darwin）用の ar」という言葉を使いましたが、 純粋に ar の機能だけを見た場合、それは単にファイルをアーカイブする処理に過ぎないため、 どの環境でもその働きは変わらないはずです。 ただし ar で作られるアーカイブ（つまり静的ライブラリ）が通常の tar アーカイブとは異なる点として、 シンボル表を持つことが挙げられます。 そのシンボル表を作るためのツールが ranlib です。 このシンボル表については環境毎に異なるため、環境毎に異なるranlibが必要になります。

「必要なコマンド群」のところでも述べましたが、 cctools-port でビルドされる ar（最終的な名前はx86_64-apple-darwin17-ar）については、 内部で x86_64-apple-darwin17-ranlib が自動的に呼び出されます （ただしSオプションを指定することでこの呼び出しを抑制することもできます）。 よってここで言う「環境によって ar が異なる」というのは、 「ar が内部で自動的に呼び出す ranlib が異なる」ということです。

ar のソースコード ar.c を見ますと、238行目ほどに下記のような記述が見られ、 少なくとも cctools-port が提供する ar については、 このような自動的な ranlib 呼び出しが確かに存在することがわかります。


/*
 * The default is to run ranlib(1) for UNIX conformance.  But if the -S
 * option is specified by the user we don't run it.
 */
if(run_ranlib){
    /* run ranlib -f or -q on the archive */
    reset_execute_list();
    add_execute_list_with_prefix("ranlib");
    if(options & AR_S)
		add_execute_list("-f");
    else
		add_execute_list("-q");
    if(toc64)
		add_execute_list("-toc64");
    add_execute_list(archive);
    if(execute_list(verbose) == 0){
		(void)fprintf(stderr, "%s: internal ranlib command failed\n",
		      progname);
		exit(EXIT_FAILURE);
    }
}

add_execute_list_with_prefix("ranlib") という関数が呼び出されておりますが、 この関数の実体はライブラリ libstuff のexecute.c 内で定義されています。 また、この execute.c 内でさらに cmd_with_prefix 関数が呼び出され、 引数 "ranlib" の先頭に PROGRAM_PREFIXマクロで定義された文字列が付加され、 この文字列が最終的に実行されるコマンド名となります。

尚、この PROGRAM_PREFIX マクロについては libstuff をビルドするための Makefile（libstuff.mak) で定義されており、 その値は "$(target_triplet)-" です。 さらにこの変数 target_triplet の値が "x86_64-apple-darwin17" となっています。 これで cctools-port の ar がどのような経路を経て x86_64-apple-darwin17-ranlib を自動的に呼び出すのかが 明らかとなりました。

尚、x86_64-apple-darwin17-ranlib については後ほど登場する misc.mak でビルドを行います。


• as-arm.mak
• as-i386.mak
• as-x86_64.mak
• as-ppc.mak
• as-ppc64.mak
• as.mak

as （アセンブラ）をビルドします。

C言語のソースコードであるため、ビルドも比較的高速ですぐに終わります。 このツールのビルドでは、最後にライブラリとして libstuff.a がリンクされます。

as（アセンブラ）とはアセンブリ言語（テキストファイル）をオブジェクトファイルに変換するためのツールです。 ただしMoaiではアセンブラを使いませんので、万一この部分のビルドでエラーが出るなどして止まる場合、 最後の手段としてこの部分のビルドを飛ばしても構いません （make_world.sh の該当する部分（make -f as-arm.mak などを実行している部分）をコメントアウトするなどすればよいでしょう）。

以下では一応、アセンブラについての簡単な説明と、これらのMakefileについての解説をしておきます。


アセンブリ言語とは機械語と一対一に対応した命令列が列挙される言語で、 C言語よりもさらに機械語に近いものとなります（というよりあらゆる言語の中で最も機械語に近い言語（機械語自身を除けば）と言ってよいでしょう）。 一般に機械語のファイル（例えばオブジェクトファイルの中身は機械語の部分を含みます）は、 バイナリファイルとなっているため人間が読むのは極めて困難ですが、 アセンブリ言語は（機械語と一対一に対応してはいるものの）それがテキストファイルで表された記述になっているため、 （バイナリファイルを直接読むことに比べれば）人間にとってはるかに読みやすいものになります。

機械語はCPUの種類によって異なります。 従ってアセンブリ言語の命令列もCPUの種類によって異なり、 一言にアセンブリ言語と言っても、例えばarm版のアセンブリ言語とi386版のアセンブリ言語では、 使われる命令列などが異なります。 それゆえ、arm版のアセンブラやi386版のアセンブラも別々に用意する必要があるわけで、 as-arm.mak は前者をビルドするための Makefile、as-i386.mak は後者をビルドするための Makefile となります。 その他の as-x86_64.mak、as-ppc.mak、as-ppc64.mak も同様で、 それぞれ x86_64版のアセンブラ、ppc（PowerPC）版のアセンブラ、ppc64（PowerPC 64bit）版のアセンブラをビルドするためのMakefileです。

これらのMakefileの中身をよく見てみると、ビルドに使われているC言語のファイルのほとんどが共通していることがわかります。 つまり同じC言語のファイルをCPUの種類毎に何度もリビルドしていることになり、 一見すると冗長です。しかしさらに注意深くコンパイルフラグを見ると、 これらは同じC言語のファイルに対し異なるマクロを定義してビルドされています。 中でこのマクロがどのように切り分けられてコンパイルされるかはわかりませんので、 ここでは念のため全てをリビルドするようにしてあります（cctools-portに付属していたオリジナルのMakefileでも そのようにビルドするようになっているため、一応それに従ったというのもあります）。

最後に as.mak というのがありますが、これは上記のMakefileでビルドした全てのアセンブラをオプションによって呼び出すラッパーです。 これのソースファイルは cctools/as/driver.c となりますが、その一番上に書かれている以下の文言が言ってしまえばすべてです。


/*
 * The assembler driver as and runs the assembler for the "-arch <arch_flag>"
 * (if given) in ../libexec/as/<arch_flag>/as or
 * ../local/libexec/as/<arch_flag>/as.  Or runs the assembler for the host
 * architecture as returned by get_arch_from_host().  The driver only checks to
 * make sure their are not multiple arch_flags and then passes all flags to the
 * assembler it will run.
 */

出だしの「The assembler driver as and runs」は少々解釈し辛い英語なので 「(It is) the assembler driver 'as' and (it) runs」との省略形と読み替えましょう。 この「as」は前置詞のasではなくアセンブラコマンドの「as」です。

すなわち、コンパイルオプション「-arch」に先ほど説明したCPUの種類<arch_flag>を指定して as コマンドを呼び出した場合、 インストールディレクトリ内の libexec/as/<arch_flag>/as が呼び出されるということです。 <arch_flag> の値は今回の場合、arm、i386、x86_64、ppc、ppc64 のいずれかになります。


• misc.mak

ディレクトリ cctools/misc 内にある各種ツールの実行バイナリをビルドします。

ここでは以下のツールがビルドされます。



bitcode_strip   check_dylib       checksyms
cmpdylib        codesign_allocate ctf_insert
indr            inout             install_name_tool
libtool         lipo              nm
nmedit          pagestuff         ranlib
redo_prebinding seg_addr_table    seg_hack
segedit         size              strings
strip


ここでは基本要件にある ranlib（最終的な名前は x86_64-apple-darwin17-ranlib） が登場しています。 ar と同じく、ranlib も静的ライブラリを作る際に使われるツールです。

その他、Moaiのビルドにおいて使う可能性があるとすれば、install_name_tool、nm、strip くらいで 正直他のツールはいらないと言えばそうなのですが、ここでは一応全てをビルドする形になります （とはいえ基本的に一つのツールにつき一つのC言語ファイルしかないので大して時間はかかりません）。

このツールのビルドでは、最後にライブラリとして libstuff.a がリンクされます。


• otool.mak

otool というツールをビルドします（ディレクトリ cctools/otool 内にあります）。

otool というコマンドはあまり聞きなれないかもしれませんが（実際、Linuxなどでは通常は存在せず、 Darwinにのみ存在するコマンドのようですが）、 MacOSX のオブジェクトファイルであるMach-O形式ファイルの内容をダンプするためのツールです。 Moaiのビルドで直接使うということはありませんが、出来上がったバイナリの妥当性をチェックしたい場合は使用するとよいでしょう。

C言語のソースコードであるため、ビルドも比較的高速ですぐに終わります。 このツールのビルドでは、最後にライブラリとして libobjc.a と libstuff.a がリンクされます。


• ld64-libBlocksRuntime.mak

libBlocksRuntime.a という静的ライブラリをビルドします。

ここからはいよいよリンカ ld64 関連のビルドとなります（ディレクトリ cctools/ld64 内のビルドです）。

このライブラリはメモリ管理やGC（ガベージコレクション）関係の処理を提供するものです。 ソースコードの置かれた位置は少し分かりにくいですが cctools/ld64/src/3rd/BlocksRuntime になります。

C言語のソースコードであるため、ビルドも比較的高速ですぐに終わります。 cctools-port の中では一番基本的なライブラリで他のライブラリに特には依存していません。


• ld64-libhelper.mak

libhelper.a という静的ライブラリをビルドします。

このライブラリは文字列処理やクイックソートなど基本的なユーティリティを提供するものです。 ソースコードの置かれた位置は少し分かりにくいですが cctools/ld64/src/3rd になります。

C言語のソースコードであるため、ビルドも比較的高速ですぐに終わります。 cctools-port の中では一番基本的なライブラリで他のライブラリに特には依存していません。


• ld64-libParsers.mak

libParsers.a という静的ライブラリをビルドします。

ソースコードの置かれた位置は少し分かりにくいですが cctools/ld64/src/ld/parsers になります。 ここから本格的に ld64 本体のビルドに入り、ソースコードもC言語からC++に変わります。 C++でのビルドの場合、（きちんと測定したわけではないですが体感的には）一つのファイルにつきC言語でのビルドの二倍以上の時間がかかる印象です。

ライブラリとしてはlibhelperを使用しており、この段階ではまだリンクまではしないものの、 cctools/ld64/src/3rd 配下にあるヘッダファイルがインクルード可能な状態にしておく必要があります。


• ld64-libPasses.mak

libPasses.a という静的ライブラリをビルドします。

ソースコードの置かれた位置は少し分かりにくいですが cctools/ld64/src/ld/passes になります。

ライブラリとしてはlibhelperやlibParsersを使用しており、この段階ではまだリンクまではしないものの、 cctools/ld64/src/3rd や cctools/ld64/src/ld/parsers 配下にあるヘッダファイルがインクルード可能な状態にしておく必要があります。

ここで言うPassとは（これについてはこの記事が想定するレベルを大きく超えますが） リンカの機能を拡張するためのプラグインのようなものを意味しています。


いわゆるコマンドを実行するためのパス(PATH)のことではありません。
cctools/ld64/src/passes 配下には様々なパス（プラグインのようなもの）が定義されており、 libPasses とは要するにそのようなプラグインの集合体です （ただしプラグインとは通常動的にロードされるものですが、 これは静的ライブラリとしてリンクされるため、厳密に言えばプラグインとも違います）。

例えば cctools/ld64/src/passes/objc.h を見ると以下のようになっていることが確認できます。


#include "Options.h"
#include "ld.hpp"


namespace ld {
namespace passes {
namespace objc {

// called by linker to optimize ObjC data structures
extern void doPass(const Options& opts, ld::Internal& internal);


} // namespace objc
} // namespace passes 
} // namespace ld 

また cctools/ld64/src/passes/dylibs.h を見ると以下のようになっていることが確認できます。


#include "Options.h"
#include "ld.hpp"


namespace ld {
namespace passes {
namespace dylibs {

// called by linker to optimize use of dylibs
extern void doPass(const Options& opts, ld::Internal& internal);


} // namespace dylibs
} // namespace passes 
} // namespace ld 

よく似ています。 というより同じでなければなりません。

両者はともに（全く同じ関数型からなる）doPass関数を実装しています （中身の実装（cppファイルに記述されておりますが）は勿論異なっています）。 リンカから見れば、これらのdoPass関数に名前空間以外の違いはなく （このことを共通のインターフェースを持つと呼びます）、 つまりリンカ本体のソースコードにおいては、 おそらくこれらの関数の呼び出しを抽象化した形で書いているはずです。 というわけで次はいよいよリンカld64の本体、ldについて見ていきましょう。


• ld64-ld.mak

リンカ ld64 の本体 ld の実行バイナリをビルドします。

ソースコードの置かれた位置は cctools/ld64/src/ld になります。

いよいよ大詰め、いわばラスボスの最終形態です。 ここでは今までビルドしてきたlibBlocksRuntime.a、libhelper.a、libParsers.a、libPasses.a をリンクすることになります （libobjc.a や libstuff.a は登場しませんが、これらは他のツールのリンクで使われており、既に役目を終えています）。 それだけではありません。 前の項で苦労してビルドした libxar.so、libtapi.so をついにここでリンクします。 その他、ここでは libLTO（llvm_clangがインストールされているディレクトリ配下にあるライブラリ）や libuuid といった外部ライブラリもリンクします。

これまで戦ってきた相手と今度は共闘してラスボスを倒すというまさに感動のクライマックスといった感じですが、 物語との違いはこの共闘する仲間が途中で裏切ってこちらが負ける（あるいは詰む）可能性があるということです。


さて、直前で見た libPasses.a での doPass 関数が ld 本体ではどう呼び出されているのか気になるところです。 本筋とは関係ありませんが、オマケとしてこれを見ておきましょう。 この呼び出しについては cctools/ld64/src/ld/ld.cpp の 1370行目から1390行目あたりに書かれています。 以下がその抜粋です。 一体どれほど巧みな抽象化がなされているのか、期待に胸が膨らみま…


		// run passes
		statistics.startPasses = mach_absolute_time();
		ld::passes::objc::doPass(options, state);
		ld::passes::stubs::doPass(options, state);
		ld::passes::huge::doPass(options, state);
		ld::passes::got::doPass(options, state);
		ld::passes::tlvp::doPass(options, state);
		ld::passes::dylibs::doPass(options, state);	// must be after stubs and GOT passes
		ld::passes::order::doPass(options, state);
		state.markAtomsOrdered();
		ld::passes::dedup::doPass(options, state);
		ld::passes::branch_shim::doPass(options, state);	// must be after stubs
		ld::passes::branch_island::doPass(options, state);	// must be after stubs and order pass
		ld::passes::dtrace::doPass(options, state);
		ld::passes::compact_unwind::doPass(options, state);  // must be after order pass
#if defined(HAVE_XAR_XAR_H) && defined(LTO_SUPPORT) // ld64-port
		ld::passes::bitcode_bundle::doPass(options, state);  // must be after dylib
#endif // HAVE_XAR_XAR_H && LTO_SUPPORT

		// Sort again so that we get the segments in order.
		state.sortSections();
		ld::passes::thread_starts::doPass(options, state);  // must be after dylib



まさかの直書ッ！？

抽象化もへったくれもなく関数テーブルさえ見当たりません！ doPass関数を愚直に呼び出して羅列しているだけだとッ！？

ならば何のために共通のインターフェースで揃えたのでしょうか？ （このld以外にもこのdoPass関数を呼び出す謎の存在がいる可能性もありますが、 これ以上の深入りはやめておきましょう）。

少々拍子抜けする結果となってしまいましたが、 まあ静的リンクする時点でこうなることはある意味必然であったのかもしれません。 あるいは将来的に抽象化し動的ロードに対応するための布石として、 とりあえず現段階でインターフェースを揃えているのかもしれません。


• ld64-other.mak

ディレクトリ cctools/ld64/src/other 内にある各種ツールの実行バイナリをビルドします。

ここでは以下のツールがビルドされます。



ObjectDump
dyldinfo
unwinddump
machocheck
objcimageinfo


※既にラスボス戦は終了しております。 これらは裏ボスというほどの相手ではありません。 これらはMoaiのビルドに直接必要でもありませんが、一応cctools-portが提供する最後のツールとして Makefileを用意しています。

これらについては、libxar.so や libtapi.so をリンクすることなくビルドすることができます。 ただしlibBlocksRuntime.a、libhelper.a、libParsers.a をリンクする必要はあります。 また外部ライブラリとして libLTO（llvm_clangがインストールされているディレクトリ配下にあるライブラリ） もリンクする必要があります。


3. 問題なく完了した場合、xar や apple-libtapi の時に作成したインストールディレクトリ（install_dir）に、 ld64を始めとしたツール群がすべてがインストールされます。

特にディレクトリ install_dir/bin、install_dir/libexec について確認してください。 すべては列挙しませんが、Moaiのビルドにおいて重要なものは以下です。



install_dir/bin/x86_64-apple-darwin17-ar
install_dir/bin/x86_64-apple-darwin17-ranlib
install_dir/bin/x86_64-apple-darwin17-ld


例えば ar の場合、インストール時に x86_64-apple-darwin17-ar へ改名しつつコピーを行っています。 リンカ ld64 の場合、最終的に x86_64-apple-darwin17-ld という名前になります。


この先、展開ディレクトリ cctools-port-927.0.2-ld64-450.3 は使いませんので、 このタイミングでこの展開ディレクトリを削除することもできます。

また、mkfalt_cctools-port/out_dir 内にあるファイルについても ビルドのために一時的に作られたファイルですので削除が可能です。 ディレクトリ out_dir ごと削除してもよいですし、 「sh make_world.sh clean」を実行することでも out_dir の中身が削除されます。

尚、当然ですがインストールディレクトリ（install_dir）の方はこの先もまだ使いますので削除してはいけません。

お疲れ様でした。 これですべてのインストールが完了です。 …と言いたいところですが、

最後の仕上げとしてMacOSX SDKを展開し、所定の位置に置いておく必要があります。 また実際にコンパイルとリンクのテストも必要です。 次はそれについて説明しましょう。

MacOSX SDKの展開とテスト

1. MacOSX10.13.sdk.tar.xz を解凍し、ディレクトリ MacOSX10.13.sdk に展開します。

よく見ると拡張子が zip ではなく xz というよくわからない形式になっています （「何でこんな変な形式で圧縮しておるのか？」と言いたくもなりますが仕方ありません）。 unzip コマンドで解凍することはおそらくできないでしょう。

xz 形式を解凍する方法はいくつかありますが、tar コマンドのバージョンが 1.22 以上の場合、それを用いるのが一番よいでしょう （tarのバージョン1.22は2009年3月にリリースされておりますので、よほど古いLinuxでなければバージョンは1.22以上になっていると思います）。 tarのバージョンは以下のようにして確認できます。



tar --version


これを実行した結果、バージョン番号が 1.22 より大きい数字であれば問題ありません。 以下のように「-J」オプションを利用して実行して解凍しましょう。



tar -Jxvf MacOSX10.13.sdk.tar.xz


万が一、バージョン番号が 1.22 より小さい場合、 素直にパッケージマネージャー等により新しい tar を本インストール（アップデート）すべきです。 それが一番確実と思われます。


一応 tar の「-J」オプションに頼らない代替案も示します。

7z コマンドがある場合、それがバージョン9.04以降である場合に限りますが、xzを解凍することができます （7zのバージョン9.04は2009年5月にリリースされております）。 7z のバージョンは以下のようにして確認できます。


7z | grep Version


あるいは以下のように i オプションを付けて実行することで xz がサポートされているか否かを直接確認することもできます。


7z i

サポートされているフォーマットのリストが表示されるはずです。 画面がスクロールして流れてしまう場合は以下のようにgrepで絞り込んで表示してもよいでしょう。


7z i | grep xz
バージョン番号が 9.04 より大きい数字であれば問題ありません。 これで一応、以下のように実行することで xz を解凍することはできます （しかしこの話にはまだ続きがあります。 特にディスクの残りサイズに余裕のない方はこれの実行は一旦保留してください）。


7z x MacOSX10.13.sdk.tar.xz

上記で確かに xz形式が解凍されるのですが、拡張子が「tar.xz」となっているため、 解凍された結果は tar ファイルとなります。 この後に tar コマンドでこの tar ファイルを展開すればすべてが終わるのですが、 今回の場合、この tar ファイルが約 570MB にもなります。 さらにこれを展開した場合、その展開ディレクトリのサイズが約 650MB です。 そのため、このように途中で一時的な tar ファイルを作る方法をとると、1.2GB弱ほどの空スペースが必要になります。 例えばディスクの空スペースが残り700MBの場合、本来であれば展開ディレクトリ自体を格納できる空きがあるにもかかわらず、 この一時的な tar ファイルのせいで最後まで解凍することができないことになります。

そこで（特にディスクサイズに余裕がない場合）このような tar ファイルを作らずに解凍する方法をとる必要があります。


7z x -so MacOSX10.13.sdk.tar.xz | tar xvf -

7z コマンドの場合、上記のように「-so」オプション（write data stdout）を付加することで 解凍データを標準出力に送ることができます。 それをパイプでtarに流し込むことで、一時的な tar ファイルを作らずに最後まで解凍することが可能になります。

結局 tar コマンドは使うわけですが、「-J」オプションは使用していないため、 tar のバージョンは何でもよいわけです （とはいえ、7zのバージョンが9.04以降の環境なら、そもそもtarのバージョンも1.22以降である可能性が高く、 tarのバージョンが1.22以降ならば最初から「-J」オプションで解凍すればよいわけではあります）。

因みに、tar に一切頼らない方法もないわけではありません。 ここまで来ると単なる趣味の領域ですが、最後にそれについて解説しておきましょう。 以下は 7z コマンドのみですべてを完結させる方法です。


7z x -so MacOSX10.13.sdk.tar.xz | 7z x -si -ttar

パイプより前（xzの解凍）は先ほどと同じです。 パイプより後（tarの展開）について、通常は tar コマンドを使うところを 7z コマンドに置き換えています。 ただし7z コマンドの場合、上記のように「-si」オプション（read data from stdin）を付加することで 解凍データを標準入力として受け取るようにする必要があります。 また、-tオプションにより展開しようとしているアーカイブのタイプを指定します。 今回の場合、アーカイブtarを展開しようとしていますので、その指定は「-ttar」となります。


その他、xz コマンドというものもありますが（というよりそもそもそれが xz 形式の本家本元であるわけですが）、 このコマンドはちょっと「いわくつき」のもので、直接実行するのはあまりお勧めできません （とはいえ現在は大丈夫であるとは思うのですが）。 またどのみちこのコマンドを利用するにしても、今回の場合 tar コマンドが必要になります。


2. SDKの展開ディレクトリ MacOSX10.13.sdk をインストールディレクトリ（install_dir）直下に移動します。

別にSDKの展開ディレクトリはどこに置いても構わないのですが （どのみち、後のリンカのオプション指定においてその場所を明示的に指定しなければなりません）、 ディレクトリ install_dir の直下に置いておく方が次で導入する環境変数ZNK_DARWIN_XC_DIRとの親和性が高いと思いますのでそうしておきます。 以下のように実行しましょう。



mv MacOSX10.13.sdk install_dir/



3. 環境変数 ZNK_DARWIN_XC_DIR にインストールディレクトリ（install_dir）のパスを設定しておきます。

別に環境変数を使わずともリンカを実行することは可能ですし、 環境変数を使うにしてもこの名前にする必要はないのですが、 この記事ではこの名前の環境変数でインストールディレクトリ（install_dir）のパスを設定するものとしましょう。 例えば以下のように実行します。



export ZNK_DARWIN_XC_DIR=$HOME/Downloads/DarwinXC/install_dir


上記のようにセットした場合、 以下のようにある程度抽象化した形でリンカを呼び出すことができます。



$(ZNK_DARWIN_XC_DIR)/bin/x86_64-apple-darwin17-ld


上記を実行するとおそらく次のように表示されるはずです。



ld: warning: directory not found for option '-F/System/Library/Frameworks/'
ld: warning: No version-min specified on command line
ld: no object files specified


本来は最後のメッセージ「ld: no object files specified」のみが表示されるべきところですが、 それより前にwarningが表示されています。

一行目の warning は MacOSX SDK の位置を指定していないために表示されています。 これについては「-syslibroot」オプションで指定します。


「-syslibroot」オプション自体は、今回に限らずクロスコンパイルにおいて重要なオプションです。 例えば標準ライブラリなどをシステムのデフォルトではないものへ切り替える場合等に指定します。

二行目の warning は -macosx_version_min を指定していないために表示されています。 それではこれらを指定して実行してみます。



$(ZNK_DARWIN_XC_DIR)/bin/x86_64-apple-darwin17-ld -syslibroot $ZNK_DARWIN_XC_DIR/MacOSX10.13.sdk -macosx_version_min 10.5.0


以下のようなエラーメッセージだけが表示されれば成功です。



ld: no object files specified


実際のリンクではさらにいくつかのオプションを付けて実行します。 毎回それを打ち込むのも大変ですので、一旦以下のようなシェルスクリプト my_ld64.sh を作っておきましょう。



#!/bin/sh
$(ZNK_DARWIN_XC_DIR)/bin/x86_64-apple-darwin17-ld \
	-demangle \
	-dynamic \
	-arch x86_64 \
	"$@" \
	-macosx_version_min 10.5.0 \
	-syslibroot $ZNK_DARWIN_XC_DIR/MacOSX10.13.sdk \
	-lcrt1.10.5.o \
	-lSystem \


これを（例えば適当なC言語ファイルtest.cがあったとして）以下のようにして実行します。



clang -target x86_64-apple-darwin17 -c test.c
sh my_ld64.sh -o test test.o


シェルスクリプト ld64.sh 内の "$@" の部分はコマンドライン引数に置き換えられると考えましょう。 上記の例では「-o test test.o」がそのままこの部分に置き換わります。

clang -target x86_64-apple-darwin17 -mmacosx-version-min=10.5.0 -o test test.o

clang -v -target x86_64-apple-darwin17 -mmacosx-version-min=10.5.0 -o test test.o

/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.5.0 -o test -lcrt1.10.5.o test.o -lSystem -lgcc_s.10.5

Moai自体のクロスコンパイルおよびインストール

1. Darwin ターミナルを開き、インストール先のパスを環境変数 ZNK_INSTALL_DIR で指定します。



export ZNK_INSTALL_DIR=$HOME/install_dir


環境変数 ZNK_INSTALL_DIR で指定されたディレクトリが存在しない場合は自動的に生成されます。 Moaiの場合、$ZNK_INSTALL_DIR/moai-v$REL_VER（$REL_VERはMoaiのバージョン番号で例えば2.3など）という名前のディレクトリが生成され、 必要なファイルがそのディレクトリ配下へとインストールされます。

特にコンパイルされた実行バイナリやライブラリなどは、$ZNK_INSTALL_DIR/moai-v$REL_VER/bin/$PLATFORM という名前のディレクトリに配置されます。 ここで $PLATFORM は実行バイナリの種類を表し、例えばDarwinにおいては、darwin17-i386、darwin17-x86_64 といった文字列になります。 Rarakuの場合も同様で、$ZNK_INSTALL_DIR/raraku-v$RRK_VER（$RRK_VERはRarakuのバージョン番号で例えば1.0など）という名前のディレクトリ配下にインストールされます。

尚、環境変数 ZNK_INSTALL_DIR が指定されていない場合は、src ディレクトリの一つ上の階層に install_dir というディレクトリが生成され、 その配下に moai-v$REL_VER や raraku-v$RRK_VER などが配置されます。


2. llvm_clangのインストール先を環境変数 ZNK_LLVM_CLANG_DIR で指定します。

このllvm_clangはxar、libtapi、ld64をビルドした際に使用したものと同じもので構いません。 これらをビルドして引き続きMoaiのビルドに入るなら、この環境変数は既に設定しているはずですので 何もする必要はありません。


Makefile_darwin.mak は環境変数 ZNK_LLVM_CLANG_DIR が定義されている場合、 llvm_clang を使用したビルドに自動的に切り替えるようになっています。 そのため、darwin17の場合、この環境変数 ZNK_LLVM_CLANG_DIR の定義は必須です。 たとえ単に「clang」と打ってllvm_clangが実行できるようになっていたとしてもです。


3. xar、libtapi、ld64のインストール先を環境変数 ZNK_DARWIN_XC_DIR で指定します。

llvm_clangはxar、libtapi、ld64をビルドして引き続きMoaiのビルドに入るなら、 この環境変数は既に設定しているはずですので 何もする必要はありません。


Makefile_darwin.mak は環境変数 ZNK_DARWIN_XC_DIR が定義されている場合、 darwin向けのクロスコンパイルに自動的に切り替えるようになっています。


4. srcディレクトリへ移動し、以下のシェルスクリプトを実行します。



cd znk_project/src
sh ./make_world.sh install


これですべてのコンパイルおよびインストールが自動で行われます。


このシェルスクリプトにより、Makefile_darwin.mak の存在する各ディレクトリへ自動的に移動しつつ make -f Makefile_darwin.mak install が実行されます。 コンパイル後の実行バイナリは各ディレクトリ内のout_dirに格納されます。

osxcross がオリジナルで用意している方法（注意点）

#=============================================================================
# Directory level rules for directory lib/Support

# Convenience name for "all" pass in the directory.
lib/Support/all: lib/Support/CMakeFiles/LLVMSupport.dir/all

.PHONY : lib/Support/all

# Convenience name for "clean" pass in the directory.
lib/Support/clean: lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/clean
lib/Support/clean: lib/Support/CMakeFiles/install-LLVMSupport.dir/clean
lib/Support/clean: lib/Support/CMakeFiles/LLVMSupport.dir/clean

.PHONY : lib/Support/clean

# Convenience name for "preinstall" pass in the directory.
lib/Support/preinstall:

.PHONY : lib/Support/preinstall

#=============================================================================
# Target rules for target lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir

# All Build rule for target.
lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/all: lib/Support/CMakeFiles/LLVMSupport.dir/all
	$(MAKE) -f lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/build.make lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/depend
	$(MAKE) -f lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/build.make lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/build
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --progress-dir=/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles --progress-num= "Built target install-LLVMSupport-stripped"
.PHONY : lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/all

# Build rule for subdir invocation for target.
lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/rule: cmake_check_build_system
	$(CMAKE_COMMAND) -E cmake_progress_start /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles 4
	$(MAKE) -f CMakeFiles/Makefile2 lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/all
	$(CMAKE_COMMAND) -E cmake_progress_start /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles 0
.PHONY : lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/rule

# Convenience name for target.
install-LLVMSupport-stripped: lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/rule

.PHONY : install-LLVMSupport-stripped

# clean rule for target.
lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/clean:
	$(MAKE) -f lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/build.make lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/clean
.PHONY : lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/clean

# clean rule for target.
clean: lib/Support/CMakeFiles/install-LLVMSupport-stripped.dir/clean

.PHONY : clean

#=============================================================================
# Target rules for target lib/Support/CMakeFiles/install-LLVMSupport.dir

# All Build rule for target.
lib/Support/CMakeFiles/install-LLVMSupport.dir/all: lib/Support/CMakeFiles/LLVMSupport.dir/all
	$(MAKE) -f lib/Support/CMakeFiles/install-LLVMSupport.dir/build.make lib/Support/CMakeFiles/install-LLVMSupport.dir/depend
	$(MAKE) -f lib/Support/CMakeFiles/install-LLVMSupport.dir/build.make lib/Support/CMakeFiles/install-LLVMSupport.dir/build
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --progress-dir=/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles --progress-num= "Built target install-LLVMSupport"
.PHONY : lib/Support/CMakeFiles/install-LLVMSupport.dir/all

# Build rule for subdir invocation for target.
lib/Support/CMakeFiles/install-LLVMSupport.dir/rule: cmake_check_build_system
	$(CMAKE_COMMAND) -E cmake_progress_start /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles 4
	$(MAKE) -f CMakeFiles/Makefile2 lib/Support/CMakeFiles/install-LLVMSupport.dir/all
	$(CMAKE_COMMAND) -E cmake_progress_start /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles 0
.PHONY : lib/Support/CMakeFiles/install-LLVMSupport.dir/rule

# Convenience name for target.
install-LLVMSupport: lib/Support/CMakeFiles/install-LLVMSupport.dir/rule

.PHONY : install-LLVMSupport

# clean rule for target.
lib/Support/CMakeFiles/install-LLVMSupport.dir/clean:
	$(MAKE) -f lib/Support/CMakeFiles/install-LLVMSupport.dir/build.make lib/Support/CMakeFiles/install-LLVMSupport.dir/clean
.PHONY : lib/Support/CMakeFiles/install-LLVMSupport.dir/clean

# clean rule for target.
clean: lib/Support/CMakeFiles/install-LLVMSupport.dir/clean

.PHONY : clean

#=============================================================================
# Target rules for target lib/Support/CMakeFiles/LLVMSupport.dir

# All Build rule for target.
lib/Support/CMakeFiles/LLVMSupport.dir/all:
	$(MAKE) -f lib/Support/CMakeFiles/LLVMSupport.dir/build.make lib/Support/CMakeFiles/LLVMSupport.dir/depend
	$(MAKE) -f lib/Support/CMakeFiles/LLVMSupport.dir/build.make lib/Support/CMakeFiles/LLVMSupport.dir/build
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --progress-dir=/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles --progress-num=48,49,50,51 "Built target LLVMSupport"
.PHONY : lib/Support/CMakeFiles/LLVMSupport.dir/all

# Include target in all.
all: lib/Support/CMakeFiles/LLVMSupport.dir/all

.PHONY : all

# Build rule for subdir invocation for target.
lib/Support/CMakeFiles/LLVMSupport.dir/rule: cmake_check_build_system
	$(CMAKE_COMMAND) -E cmake_progress_start /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles 4
	$(MAKE) -f CMakeFiles/Makefile2 lib/Support/CMakeFiles/LLVMSupport.dir/all
	$(CMAKE_COMMAND) -E cmake_progress_start /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles 0
.PHONY : lib/Support/CMakeFiles/LLVMSupport.dir/rule

# Convenience name for target.
LLVMSupport: lib/Support/CMakeFiles/LLVMSupport.dir/rule

.PHONY : LLVMSupport

# clean rule for target.
lib/Support/CMakeFiles/LLVMSupport.dir/clean:
	$(MAKE) -f lib/Support/CMakeFiles/LLVMSupport.dir/build.make lib/Support/CMakeFiles/LLVMSupport.dir/clean
.PHONY : lib/Support/CMakeFiles/LLVMSupport.dir/clean

# clean rule for target.
clean: lib/Support/CMakeFiles/LLVMSupport.dir/clean

.PHONY : clean

make -f Makefile2 lib/Support/CMakeFiles/LLVMSupport.dir/all

make -f lib/Support/CMakeFiles/LLVMSupport.dir/build.make

# build rule for target.
LLVMSupport: cmake_check_build_system
	$(MAKE) -f CMakeFiles/Makefile2 LLVMSupport
.PHONY : LLVMSupport

# Build rule for subdir invocation for target.
lib/Support/CMakeFiles/LLVMSupport.dir/rule: cmake_check_build_system
	$(CMAKE_COMMAND) -E cmake_progress_start /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles 4
	$(MAKE) -f CMakeFiles/Makefile2 lib/Support/CMakeFiles/LLVMSupport.dir/all
	$(CMAKE_COMMAND) -E cmake_progress_start /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles 0
.PHONY : lib/Support/CMakeFiles/LLVMSupport.dir/rule

# Convenience name for target.
LLVMSupport: lib/Support/CMakeFiles/LLVMSupport.dir/rule

.PHONY : LLVMSupport

LLVMSupport
→ lib/Support/CMakeFiles/LLVMSupport.dir/rule
→ lib/Support/CMakeFiles/LLVMSupport.dir/all

echo ""
echo "## Building clangBasic ##"
echo ""

$MAKE clangBasic -j $JOBS

echo ""
echo "## Building libtapi ##"
echo ""

$MAKE libtapi -j $JOBS

#=============================================================================
# Target rules for target projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir

# All Build rule for target.
projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/all: lib/Demangle/CMakeFiles/LLVMDemangle.dir/all
projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/all: lib/Support/CMakeFiles/LLVMSupport.dir/all
projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/all: lib/IR/CMakeFiles/LLVMCore.dir/all
projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/all: lib/BinaryFormat/CMakeFiles/LLVMBinaryFormat.dir/all
projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/all: lib/Bitcode/Reader/CMakeFiles/LLVMBitReader.dir/all
projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/all: lib/MC/CMakeFiles/LLVMMC.dir/all
projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/all: lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/all
projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/all: lib/Object/CMakeFiles/LLVMObject.dir/all
projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/all: projects/clang/lib/Basic/CMakeFiles/clangBasic.dir/all
projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/all: projects/libtapi/lib/Core/CMakeFiles/tapiCore.dir/all
projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/all: projects/libtapi/tools/libtapi/CMakeFiles/libtapi_exports.dir/all
	$(MAKE) -f projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/build.make projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/depend
	$(MAKE) -f projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/build.make projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/build
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --progress-dir=/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles --progress-num= "Built target libtapi"
.PHONY : projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/all

# Include target in all.
all: projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/all

.PHONY : all

# Build rule for subdir invocation for target.
projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/rule: cmake_check_build_system
	$(CMAKE_COMMAND) -E cmake_progress_start /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles 16
	$(MAKE) -f CMakeFiles/Makefile2 projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/all
	$(CMAKE_COMMAND) -E cmake_progress_start /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles 0
.PHONY : projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/rule

# Convenience name for target.
libtapi: projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/rule

.PHONY : libtapi

libtapi
→ projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/rule
→ projects/libtapi/tools/libtapi/CMakeFiles/libtapi.dir/all

set( LLVM_LINK_COMPONENTS
  Object
  BinaryFormat
  )

add_tapi_library(tapiCore
  Architecture.cpp
  ArchitectureSet.cpp
  ArchitectureSupport.cpp
  API.cpp
  APIPrinter.cpp
  APIVisitor.cpp
  AvailabilityInfo.cpp
  FakeSymbols.cpp
  FileManager.cpp
  FileSystem.cpp
  Framework.cpp
  ExtendedInterfaceFile.cpp
  HeaderFile.cpp
  InterfaceFile.cpp
  InterfaceFileBase.cpp
  InterfaceFileManager.cpp
  JSONFile.cpp
  MachODylibReader.cpp
  Path.cpp
  Platform.cpp
  ReexportFileWriter.cpp
  Registry.cpp
  Symbol.cpp
  TapiError.cpp
  TextStub_v1.cpp
  TextStub_v2.cpp
  TextStub_v3.cpp
  Utils.cpp
  XPI.cpp
  XPISet.cpp
  YAML.cpp
  YAMLReaderWriter.cpp

  LINK_LIBS
  clangBasic
  )

# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 3.13

# Delete rule output on recipe failure.
.DELETE_ON_ERROR:


#=============================================================================
# Special targets provided by cmake.

# Disable implicit rules so canonical targets will work.
.SUFFIXES:


# Remove some rules from gmake that .SUFFIXES does not remove.
SUFFIXES =

.SUFFIXES: .hpux_make_needs_suffix_list


# Suppress display of executed commands.
$(VERBOSE).SILENT:


# A target that is always out of date.
cmake_force:

.PHONY : cmake_force

#=============================================================================
# Set environment variables for the build.

# The shell in which to execute make rules.
SHELL = /bin/sh

# The CMake executable.
CMAKE_COMMAND = /home/zenkaku/Downloads/cmake_dir/install_dir/bin/cmake

# The command to remove a file.
RM = /home/zenkaku/Downloads/cmake_dir/install_dir/bin/cmake -E remove -f

# Escaping for special characters.
EQUALS = =

# The top-level source directory on which CMake was run.
CMAKE_SOURCE_DIR = /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm

# The top-level build directory on which CMake was run.
CMAKE_BINARY_DIR = /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build

# Include any dependencies generated for this target.
include lib/Support/CMakeFiles/LLVMSupport.dir/depend.make

# Include the progress variables for this target.
include lib/Support/CMakeFiles/LLVMSupport.dir/progress.make

# Include the compile flags for this target's objects.
include lib/Support/CMakeFiles/LLVMSupport.dir/flags.make

# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 3.13

# compile C with /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang
# compile CXX with /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++
C_FLAGS =  -fPIC -Werror=date-time -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wdelete-non-virtual-dtor -Wstring-conversion -ffunction-sections -fdata-sections -O3 -DNDEBUG  

C_DEFINES = -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS

C_INCLUDES = -I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support -I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support -I/usr/include/libxml2 -I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/include -I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/include 

CXX_FLAGS = -I /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/../src/llvm/projects/clang/include -I /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/projects/clang/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -ffunction-sections -fdata-sections -O3 -DNDEBUG  

CXX_DEFINES = -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS

CXX_INCLUDES = -I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support -I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support -I/usr/include/libxml2 -I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/include -I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/include 

# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 3.13

# compile C with /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang
# compile CXX with /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++
C_FLAGS = \
	-fPIC -Werror=date-time \
	-Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers \
	-pedantic -Wno-long-long -Wcovered-switch-default -Wdelete-non-virtual-dtor -Wstring-conversion \
	-ffunction-sections -fdata-sections -O3 -DNDEBUG  

C_DEFINES = \
	-DGTEST_HAS_RTTI=0 \
	-D_GNU_SOURCE \
	-D__STDC_CONSTANT_MACROS \
	-D__STDC_FORMAT_MACROS \
	-D__STDC_LIMIT_MACROS \

C_INCLUDES = \
	-I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support \
	-I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support \
	-I/usr/include/libxml2 \
	-I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/include \
	-I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/include  \

CXX_FLAGS = \
	-I /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/../src/llvm/projects/clang/include \
	-I /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/projects/clang/include \
	-fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 \
	-Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers \
	-pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion \
	-ffunction-sections -fdata-sections -O3 -DNDEBUG  

CXX_DEFINES = \
	-DGTEST_HAS_RTTI=0 \
	-D_GNU_SOURCE \
	-D__STDC_CONSTANT_MACROS \
	-D__STDC_FORMAT_MACROS \
	-D__STDC_LIMIT_MACROS \

CXX_INCLUDES = \
	-I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support \
	-I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support \
	-I/usr/include/libxml2 \
	-I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/include \
	-I/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/include \

/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm
/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build

CMAKE_SOURCE_DIR = /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm

# The top-level build directory on which CMake was run.
CMAKE_BINARY_DIR = /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build

C_INCLUDES = \
	-I$(CMAKE_BINARY_DIR)/lib/Support \
	-I$(CMAKE_SOURCE_DIR)/lib/Support \
	-I/usr/include/libxml2 \
	-I$(CMAKE_BINARY_DIR)/include \
	-I$(CMAKE_SOURCE_DIR)/include  \

CXX_FLAGS = \
	-I $(CMAKE_SOURCE_DIR)/projects/clang/include \
	-I $(CMAKE_BINARY_DIR)/projects/clang/include \
	-fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 \
	-Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers \
	-pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion \
	-ffunction-sections -fdata-sections -O3 -DNDEBUG  

CXX_INCLUDES = \
	-I$(CMAKE_BINARY_DIR)/lib/Support \
	-I$(CMAKE_SOURCE_DIR)/lib/Support \
	-I/usr/include/libxml2 \
	-I$(CMAKE_BINARY_DIR)/include \
	-I$(CMAKE_SOURCE_DIR)/include \

CMAKE_SOURCE_DIR = src/llvm

# The top-level build directory on which CMake was run.
CMAKE_BINARY_DIR = .

lib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.o: lib/Support/CMakeFiles/LLVMSupport.dir/flags.make
lib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.o: /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/AMDGPUMetadata.cpp
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --progress-dir=/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles --progress-num=$(CMAKE_PROGRESS_1) "Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.o"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++  $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -o CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.o -c /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/AMDGPUMetadata.cpp

lib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.i: cmake_force
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green "Preprocessing CXX source to CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.i"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -E /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/AMDGPUMetadata.cpp > CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.i

lib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.s: cmake_force
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green "Compiling CXX source to assembly CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.s"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -S /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/AMDGPUMetadata.cpp -o CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.s

lib/Support/CMakeFiles/LLVMSupport.dir/APFloat.cpp.o: lib/Support/CMakeFiles/LLVMSupport.dir/flags.make
lib/Support/CMakeFiles/LLVMSupport.dir/APFloat.cpp.o: /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/APFloat.cpp
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --progress-dir=/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles --progress-num=$(CMAKE_PROGRESS_2) "Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/APFloat.cpp.o"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++  $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -o CMakeFiles/LLVMSupport.dir/APFloat.cpp.o -c /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/APFloat.cpp

lib/Support/CMakeFiles/LLVMSupport.dir/APFloat.cpp.i: cmake_force
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green "Preprocessing CXX source to CMakeFiles/LLVMSupport.dir/APFloat.cpp.i"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -E /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/APFloat.cpp > CMakeFiles/LLVMSupport.dir/APFloat.cpp.i

lib/Support/CMakeFiles/LLVMSupport.dir/APFloat.cpp.s: cmake_force
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green "Compiling CXX source to assembly CMakeFiles/LLVMSupport.dir/APFloat.cpp.s"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -S /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/APFloat.cpp -o CMakeFiles/LLVMSupport.dir/APFloat.cpp.s

lib/Support/CMakeFiles/LLVMSupport.dir/APInt.cpp.o: lib/Support/CMakeFiles/LLVMSupport.dir/flags.make
lib/Support/CMakeFiles/LLVMSupport.dir/APInt.cpp.o: /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/APInt.cpp
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --progress-dir=/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles --progress-num=$(CMAKE_PROGRESS_3) "Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/APInt.cpp.o"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++  $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -o CMakeFiles/LLVMSupport.dir/APInt.cpp.o -c /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/APInt.cpp

lib/Support/CMakeFiles/LLVMSupport.dir/APInt.cpp.i: cmake_force
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green "Preprocessing CXX source to CMakeFiles/LLVMSupport.dir/APInt.cpp.i"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -E /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/APInt.cpp > CMakeFiles/LLVMSupport.dir/APInt.cpp.i

lib/Support/CMakeFiles/LLVMSupport.dir/APInt.cpp.s: cmake_force
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green "Compiling CXX source to assembly CMakeFiles/LLVMSupport.dir/APInt.cpp.s"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -S /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/APInt.cpp -o CMakeFiles/LLVMSupport.dir/APInt.cpp.s

	…1400行以上もあるので途中略…

lib/Support/CMakeFiles/LLVMSupport.dir/Valgrind.cpp.o: lib/Support/CMakeFiles/LLVMSupport.dir/flags.make
lib/Support/CMakeFiles/LLVMSupport.dir/Valgrind.cpp.o: /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/Valgrind.cpp
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --progress-dir=/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles --progress-num=$(CMAKE_PROGRESS_110) "Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Valgrind.cpp.o"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++  $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -o CMakeFiles/LLVMSupport.dir/Valgrind.cpp.o -c /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/Valgrind.cpp

lib/Support/CMakeFiles/LLVMSupport.dir/Valgrind.cpp.i: cmake_force
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green "Preprocessing CXX source to CMakeFiles/LLVMSupport.dir/Valgrind.cpp.i"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -E /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/Valgrind.cpp > CMakeFiles/LLVMSupport.dir/Valgrind.cpp.i

lib/Support/CMakeFiles/LLVMSupport.dir/Valgrind.cpp.s: cmake_force
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green "Compiling CXX source to assembly CMakeFiles/LLVMSupport.dir/Valgrind.cpp.s"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -S /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/Valgrind.cpp -o CMakeFiles/LLVMSupport.dir/Valgrind.cpp.s

lib/Support/CMakeFiles/LLVMSupport.dir/Watchdog.cpp.o: lib/Support/CMakeFiles/LLVMSupport.dir/flags.make
lib/Support/CMakeFiles/LLVMSupport.dir/Watchdog.cpp.o: /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/Watchdog.cpp
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --progress-dir=/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles --progress-num=$(CMAKE_PROGRESS_111) "Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Watchdog.cpp.o"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++  $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -o CMakeFiles/LLVMSupport.dir/Watchdog.cpp.o -c /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/Watchdog.cpp

lib/Support/CMakeFiles/LLVMSupport.dir/Watchdog.cpp.i: cmake_force
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green "Preprocessing CXX source to CMakeFiles/LLVMSupport.dir/Watchdog.cpp.i"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -E /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/Watchdog.cpp > CMakeFiles/LLVMSupport.dir/Watchdog.cpp.i

lib/Support/CMakeFiles/LLVMSupport.dir/Watchdog.cpp.s: cmake_force
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green "Compiling CXX source to assembly CMakeFiles/LLVMSupport.dir/Watchdog.cpp.s"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && /home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -S /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/Watchdog.cpp -o CMakeFiles/LLVMSupport.dir/Watchdog.cpp.s

...途中省略…

lib/libLLVMSupport.a: lib/Support/CMakeFiles/LLVMSupport.dir/link.txt
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --bold --progress-dir=/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles --progress-num=$(CMAKE_PROGRESS_112) "Linking CXX static library ../libLLVMSupport.a"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && $(CMAKE_COMMAND) -P CMakeFiles/LLVMSupport.dir/cmake_clean_target.cmake
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && $(CMAKE_COMMAND) -E cmake_link_script CMakeFiles/LLVMSupport.dir/link.txt --verbose=$(VERBOSE)

# Rule to build all files generated by this target.
lib/Support/CMakeFiles/LLVMSupport.dir/build: lib/libLLVMSupport.a

.PHONY : lib/Support/CMakeFiles/LLVMSupport.dir/build

... 以下省略 ...

lib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.o: \
	/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/AMDGPUMetadata.cpp
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green \
		--progress-dir=/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles \
		--progress-num=$(CMAKE_PROGRESS_1) "Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.o"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && \
		/home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ \
		$(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti \
		-o CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.o \
		-c /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/AMDGPUMetadata.cpp

lib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.o: \
	/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/AMDGPUMetadata.cpp
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green \
		--progress-dir=/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles \
		--progress-num=$(CMAKE_PROGRESS_1) "Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.o"
	/home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ \
		$(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti \
		-o lib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.o \
		-c /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/AMDGPUMetadata.cpp

lib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.o: \
	/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/AMDGPUMetadata.cpp
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green \
		--progress-dir=/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles \
		--progress-num=$(CMAKE_PROGRESS_1) "Building CXX object $@"
	/home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ \
		$(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti \
		-o $@ \
		-c $<

lib/Support/CMakeFiles/LLVMSupport.dir/%.cpp.o: \
	/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/src/llvm/lib/Support/%.cpp
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green \
		--progress-dir=/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles \
		--progress-num=$(CMAKE_PROGRESS_1) "Building CXX object $@"
	/home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ \
		$(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti \
		-o $@ \
		-c $<

lib/Support/CMakeFiles/LLVMSupport.dir/%.cpp.o: $(CMAKE_SOURCE_DIR)/lib/Support/%.cpp
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green \
		--progress-dir=$(CMAKE_BINARY_DIR)/CMakeFiles \
		--progress-num=$(CMAKE_PROGRESS_1) "Building CXX object $@"
	/home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ \
		$(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti \
		-o $@ \
		-c $<

lib/Support/CMakeFiles/LLVMSupport.dir/%.cpp.o: $(CMAKE_SOURCE_DIR)/lib/Support/%.cpp
	/home/zenkaku/Downloads/llvm_dir/v3.9/install_dir/bin/clang++ \
		$(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS)  -fno-exceptions -fno-rtti -o $@ -c $<

lib/libLLVMSupport.a: lib/Support/CMakeFiles/LLVMSupport.dir/link.txt
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --bold \
		--progress-dir=/home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/CMakeFiles \
		--progress-num=$(CMAKE_PROGRESS_112) "Linking CXX static library ../libLLVMSupport.a"
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && \
		$(CMAKE_COMMAND) -P CMakeFiles/LLVMSupport.dir/cmake_clean_target.cmake
	cd /home/zenkaku/Downloads/osxcross-v1.1/osxcross-osxcross-1.1/build/apple-libtapi/build/lib/Support && \
		$(CMAKE_COMMAND) -E cmake_link_script CMakeFiles/LLVMSupport.dir/link.txt --verbose=$(VERBOSE)

/usr/bin/ar qc ../libLLVMSupport.a  \
	CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.o \
	...途中略（オブジェクトファイルの大群）... \
	CMakeFiles/LLVMSupport.dir/Watchdog.cpp.o \

/usr/bin/ranlib ../libLLVMSupport.a

function git_clone_repository
{
  local url=$1
  local branch=$2
  local project_name=$3

  if [ -n "$TP_OSXCROSS_DEV" ]; then
    # copy files from local working directory
    rm -rf $project_name
    cp -r $TP_OSXCROSS_DEV/$project_name .
    if [ -e ${project_name}/.git ]; then
      pushd $project_name &>/dev/null
      git clean -fdx &>/dev/null
      popd &>/dev/null
    fi
    f_res=1
    return
  fi

  if [ ! -d $project_name ]; then
    git clone $url $args $project_name --depth 1
  fi

  pushd $project_name &>/dev/null

  git reset --hard &>/dev/null
  git clean -fdx &>/dev/null

  if git show-ref refs/heads/$branch &>/dev/null; then
    git fetch origin $branch
  else
    git fetch origin $branch:$branch --depth 1
  fi
  
  git checkout $branch
  git pull origin $branch

  local new_hash=$(git rev-parse HEAD)
  local old_hash=""
  local hash_file="$BUILD_DIR/.${project_name}_git_hash"

  if [ -f $hash_file ]; then
    old_hash=$(cat $hash_file)
  fi

  echo -n $new_hash > $hash_file

  if [ "$old_hash" != "$new_hash" ]; then
    f_res=1
  else
    f_res=0
  fi

  popd &>/dev/null
}

  if [ ! -d $project_name ]; then
    git clone $url $args $project_name --depth 1
  else
    # this project dir already exists.
    f_res=0
    return
  fi

function build_xar()
{
  pushd $BUILD_DIR &>/dev/null

  get_sources https://github.com/tpoechtrager/xar.git master

  if [ $f_res -eq 1 ]; then
    pushd $CURRENT_BUILD_PROJECT_NAME/xar &>/dev/null
    CFLAGS+=" -w" \
      ./configure --prefix=$TARGET_DIR
    $MAKE -j$JOBS
    $MAKE install -j$JOBS
    popd &>/dev/null
    build_success
  fi

  popd &>/dev/null
}

function build_xar()
{
  pushd $BUILD_DIR &>/dev/null

  get_sources https://github.com/tpoechtrager/xar.git master

  if [ $f_res -eq 1 ]; then
    pushd $CURRENT_BUILD_PROJECT_NAME/xar &>/dev/null

	# if Makefile does not exists
    if test ! -e Makefile ; then
      CFLAGS+=" -w" \
        ./configure --prefix=$TARGET_DIR
    fi

    $MAKE -j$JOBS
    $MAKE install -j$JOBS
    popd &>/dev/null
    build_success
  fi

  popd &>/dev/null
}

# rm -rf build.sh

osxcross がオリジナルで用意している方法（実際の手順）

cmake --version

# Write CMake version
cmake_report cmVersionConfig.h${_tmp} "#define CMake_VERSION_MAJOR ${cmake_version_major}"
cmake_report cmVersionConfig.h${_tmp} "#define CMake_VERSION_MINOR ${cmake_version_minor}"
cmake_report cmVersionConfig.h${_tmp} "#define CMake_VERSION_PATCH ${cmake_version_patch}"
cmake_report cmVersionConfig.h${_tmp} "#define CMake_VERSION \"${cmake_version}\""

# Load version information.
cmake_version_major="`cmake_version_component MAJOR`"
cmake_version_minor="`cmake_version_component MINOR`"
cmake_version_patch="`cmake_version_component PATCH`"
cmake_version="${cmake_version_major}.${cmake_version_minor}.${cmake_version_patch}"

# Version number extraction function.
cmake_version_component()
{
  sed -n "
/^set(CMake_VERSION_${1}/ {s/set(CMake_VERSION_${1} *\([0-9]*\))/\1/;p;}
" "${cmake_source_dir}/Source/CMakeVersion.cmake"
}

cd $HOME/Downloads
mkdir -p cmake_dir
mv cmake-3.13.5.tar.gz cmake_dir/

cd cmake_dir
tar xvzf cmake-3.13.5.tar.gz

./bootstrap --prefix=../install_dir
make
make install

export PATH=$HOME/Downloads/cmake_dir/install_dir:$PATH

• osxcross v1.5 をダウンロードする場合
画面上方の真ん中よりやや右にある「Code」と書かれた緑色のボタンを押すと、 「Download ZIP」と表示されたプルダウンメニューが出るはずです。 このメニューから「Download ZIP」を選びます。 osxcross-master.zip という名前のファイルをダウンロードすることができますが、 これが osxcross v1.5 の本体です。


• osxcross v1.1 をダウンロードする場合
osxcross v1.1 の場合、画面左上にある「master」と書かれたボタンを押すと、 「Switch branches/tags」というタイトルのプルダウンメニューが出るはずです。

このメニューから「osxcross-1.1」を選ぶと 先ほど「master」と書かれていたボタンの名前が「osxcross-1.1」という名前に変わります （そもそもページ自体が新しいものに遷移し、URLもこの時点で最後が「osxcross-1.1」に変化しているはずです）。 ここから先は osxcross v1.5 と同様に、画面上方の真ん中よりやや右にある「Code」と書かれた緑色のボタンからファイルをダウンロードします。 「Download ZIP」と表示されたプルダウンメニューが表示されますから、 このメニューから「Download ZIP」を選びます。 osxcross-osxcross-1.1.zip という名前のファイルをダウンロードすることができますが、 これが osxcross v1.1 の本体です。

/****************************** v1.5 *********************************/

Changed:
 * Updated cctools to 986 and ld64 to 711
 * Update TAPI library to 1300.6.5

/****************************** v1.1 *********************************/

Added:
 * ... back support for OpenBSD

Changed:
 * Updated cctools to 927.0.2 and ld64 to 450.3
 * TARGET_DIR can now be configured via env
   (TARGET_DIR=<path> ./build.sh)
 * Various other improvements and fixes

/****************************** v1.3 *********************************/

Added:
 * Support for arm64 and arm64e targets

Changed:
 * Updated TAPI library to 1100.0.11

/****************************** v1.2 *********************************/

Added:
 * Support for ld64 '-lto_library <path>'

Changed:
 * Updated cctools to 949.0.1 and ld64 to 512.4

Removed:
 * Support for <= 10.5 SDKs. Use 'osxcross-1.1' branch for these.

  #get_sources https://github.com/tpoechtrager/apple-libtapi.git 1300.6.5
  get_sources https://github.com/tpoechtrager/apple-libtapi.git 1100.0.11

#CCTOOLS_VERSION=986
#LINKER_VERSION=711
CCTOOLS_VERSION=949.0.1
LINKER_VERSION=512.4

付属ライブラリlibresslについて

• src フォルダ直下の make_world.bat または make_world.sh を初めて実行した場合、この libressl も自動的にビルドされます。


• src フォルダ直下の make_world.bat または make_world.sh により clean を実行した場合、libresslの配下は clean されません。
  
  
  Note.
  
  proj_list_skip_clean.bat(proj_list_skip_clean.sh) というファイルによって、これらが clean されないように設定してあります。 なぜこのようにしているのかと言えば、libressl のコンパイルは時間がかかることと、Moai自体のバージョンが上がっても、libressl自体は通常はコンパイルし直す必要性はないものと考えられるからです。
  
  
• libressl単体をビルドしたい場合は、libressl フォルダ内に入り、その中にある make_world.bat または make_world.sh を実行します。 尚、このフォルダ内で make_world.bat または make_world.sh により clean を実行した場合は、( src フォルダ直下の場合と異なり )今度は libressl 全体が clean されます。

This article was written by:

Mr.Moai

@znk project

Zenkaku

@znk project

2026/04/30

• 一番上へ
• Moaiドキュメント(オンライン)
• znk_project(github)