「クロスコンパイルツールパッケージガイドライン」の版間の差分
Kusakata.bot (トーク | 投稿記録) 細 (文字列「http://www.gnu.org/」を「https://www.gnu.org/」に置換) |
Kusakata.bot (トーク | 投稿記録) 細 (文字列「http://wiki.debian.org/」を「https://wiki.debian.org/」に置換) |
||
40行目: | 40行目: | ||
== パッケージの名前 == |
== パッケージの名前 == |
||
− | パッケージの名前の前に {{Ic|cross-}} という単語は付けません (昔はそういった話もありましたが、パッケージの名前が長くなるという理由で公式パッケージには取り入れられませんでした)。パッケージ名には [ |
+ | パッケージの名前の前に {{Ic|cross-}} という単語は付けません (昔はそういった話もありましたが、パッケージの名前が長くなるという理由で公式パッケージには取り入れられませんでした)。パッケージ名には [https://wiki.debian.org/Multiarch/Tuples GNU triplet] によって付けられる名前を前に付けるだけでベンダーフィールドは入りませんしベンダーフィールドを "unknown" としたりはしません。例: {{Ic|arm-linux-gnueabihf-gcc}}。さらに短い名前を付ける例もありますが (例: {{Ic|mips-gcc}})、推奨されません。 |
== ファイルの保存場所 == |
== ファイルの保存場所 == |
2018年2月6日 (火) 23:44時点における版
32ビット – CLR – クロス – Eclipse – Electron – Free Pascal – GNOME – Go – Haskell – Java – KDE – カーネル – Lisp – MinGW – Node.js – ノンフリー – OCaml – Perl – PHP – Python – R – Ruby – Rust – VCS – ウェブ – Wine
目次
特記事項
このページでは [community]
に入っている以下のパッケージに基づいた、新しいパッケージ方法を説明しています:
- mingw-w64-gccAUR などの
mingw-w64-*
シリーズのパッケージ - arm-none-eabi-gcc などの
arm-none-eabi-*
シリーズのパッケージ - arm-wince-cegcc-gccAUR[リンク切れ: アーカイブ: aur-mirror] などの
arm-wince-cegcc-*
シリーズのパッケージ
バージョン互換性
以下の方針に従うことで互換性のあるバージョンの gcc, binutils, カーネル, C ライブラリを選択できます:
- 一般的なルール:
- gcc と binutils のリリースには相関関係があります。同時にリリースされたバージョンを使ってください。
- libc をコンパイルするときは最新のカーネルヘッダーを使用したほうが良いですが
--enable-kernel
スイッチを使うことで古いカーネルでも動作するようになります (あくまで glibc の話で、他の C ライブラリでは事情が異なります)。
- 公式リポジトリ: 修正や変更を加える必要がある場合もありますが、基本的には Arch Linux が使用しているバージョンを使うほうが動作する可能性が高くなります。
- ソフトウェアドキュメント: 全ての GNU ソフトウェアには
README
とNEWS
ファイルが存在し、最低要件として必要とするソフトウェアのバージョンなどが記載されています。 - 他のディストリビューション: 他のディストリビューションもクロスコンパイラを行っています。
- http://clfs.org にはクロスコンパイラをビルドするのに必要な手順や最新バージョンについて説明があります。
クロスコンパイラのビルド
クロスコンパイラは一般的に以下の手順でビルドされます:
- binutils: クロスコンパイル用の binutils をビルド。
- headers: ターゲットアーキテクチャの C ライブラリとカーネルヘッダをインストール。
- リファレンスヘッダーとして linux-api-headers を使用して make に
ARCH=target-architecture
と指定してください。 - libc ヘッダーパッケージの作成 (Glibc の場合は こちら に手順が書かれています)。
- リファレンスヘッダーとして linux-api-headers を使用して make に
- gcc-stage-1: 基本の (stage 1) gcc クロスコンパイラをビルド。C ライブラリをコンパイルするのに使用します。C ライブラリ以外のものをビルドすることはできません (C ライブラリが使えないため)。
- libc: クロスコンパイル用の C ライブラリをビルド (stage 1 のクロスコンパイラを使用)。
- gcc-stage-2: 完全な (stage 2) C クロスコンパイラをビルド。
ヘッダーや libc のソースはプラットフォームによって変わります。
パッケージの名前
パッケージの名前の前に cross-
という単語は付けません (昔はそういった話もありましたが、パッケージの名前が長くなるという理由で公式パッケージには取り入れられませんでした)。パッケージ名には GNU triplet によって付けられる名前を前に付けるだけでベンダーフィールドは入りませんしベンダーフィールドを "unknown" としたりはしません。例: arm-linux-gnueabihf-gcc
。さらに短い名前を付ける例もありますが (例: mips-gcc
)、推奨されません。
ファイルの保存場所
最新版の gcc や binutils は sysroot やライブラリのパスが衝突することはありません。実行ファイルは /usr/bin/
に置くことができます。衝突しないように実行ファイルにはアーキテクチャの名前を前に付けます。
基本的に ./configure
には最低でも以下のパラメータが必要です:
_target=<your-target> # e.g. i686-pc-mingw32 _sysroot=/usr/lib/${_target} ... ./configure \ --prefix=${_sysroot} --sysroot=${_sysroot} \ --bindir=/usr/bin
サンプル
以下は MinGW 用の binutils の PKGBUILD です。特に参考になる点は:
- クロス環境のルートディレクトリを指定しています。
${_pkgname}
,${_target}
,${_sysroot}
変数を使用してコードを読みやすいようにしています。- 重複・衝突するファイルを消しています。
# Maintainer: Allan McRae <allan@archlinux.org> # cross toolchain build order: binutils, headers, gcc (pass 1), w32api, mingwrt, gcc (pass 2) _target=i686-pc-mingw32 _sysroot=/usr/lib/${_target} pkgname=${_target}-binutils _pkgname=binutils pkgver=2.19.1 pkgrel=1 pkgdesc="MinGW Windows binutils" arch=('i686' 'x86_64') url="https://www.gnu.org/software/binutils/" license=('GPL') depends=('glibc>=2.10.1' 'zlib') options=('!libtool' '!distcc' '!ccache') source=(http://ftp.gnu.org/gnu/${_pkgname}/${_pkgname}-${pkgver}.tar.bz2) md5sums=('09a8c5821a2dfdbb20665bc0bd680791') build() { cd ${srcdir}/${_pkgname}-${pkgver} mkdir binutils-build && cd binutils-build ../configure --prefix=${_sysroot} --bindir=/usr/bin \ --with-sysroot=${_sysroot} \ --build=$CHOST --host=$CHOST --target=${_target} \ --with-gcc --with-gnu-as --with-gnu-ld \ --enable-shared --without-included-gettext \ --disable-nls --disable-debug --disable-win32-registry make make DESTDIR=${pkgdir}/ install # clean-up cross compiler root rm -r ${pkgdir}/${_sysroot}/{info,man} }
トラブルシューティング
コンパイルが失敗したときのメッセージの意味がわからない
configure
の実行時に発生するエラーについては $srcdir/pkgname-build/config.log
を読んでください。コンパイル時に発生するエラーについてはコンソールのログを上まで見るか "error" という単語で検索するしかありません。
よくあるエラーの原因
- コンパイルフラグが多すぎるか少なすぎる。問題ないとわかっているフラグを使ってみてください。
- 依存関係が壊れている。例えば binutils のファイルが欠けていたり保存場所が間違っていると gcc の configure 時に謎めいたエラーが発生します。
build()
関数にexport CFLAGS=""
を追加していない (GCC Bugzilla の bug 25672 を参照)。--prefix
/--with-sysroot
で指定したディレクトリに書き込む権限がない (clfs のガイドでわかりにくいところです)。- sysroot にカーネルや libc のヘッダーが存在しない。
- Google で検索しても解決しない場合、今の構成を諦めて、もっと安定している、動作することが確認されている設定を使ってみてください。
ファイルが間違った場所にインストールされる
make install
を実行するときの作法は様々であり結果も違います。例えば、プラットフォームによっては DESTDIR
がサポートされておらず代わりに install_root
を使う必要があります。tooldir
や prefix
などの引数も同じです。環境変数のかわりに引数としてパラメータを指定することもあります。例えば以下のようにするところを:
CC=arm-elf-gcc ./configure
以下のように実行することがあります:
./configure CC=arm-elf-gcc
逆にすることでコンパイル結果が変わります (configure/make が再帰的に自己実行されることが原因です)。