MinGW 软件包指南

来自 ArchWiki
（重定向自 MinGW PKGBUILD Guidelines）
Arch 软件包指南

32 位 – CLR – CMake – 交叉编译 – DKMS – Eclipse – Electron – 字体 – Free Pascal – GNOME – Go – Haskell – Java – KDE – 内核模块 – Lisp – Meson – MinGW – Node.js – 非自由软件 – OCaml – Perl – PHP – Python – R – Ruby – Rust - 安全 – Shell – VCS – Web – Wine

此页面解释了如何为在 Windows 上运行的软件编写 PKGBUILD。

为了在 Linux 上为 Windows 构建软件，需要：

  • Windows 头文件和导入库，用于 WinAPI 和 C 标准库。 有两种获取方式：
    • mingw-w64：提供 32 位和 64 位工具链，支持安全 crt、Vista+ API、DDK (ReactOS) 和 DirectX (WINE)。 有关受支持功能以及与旧版 MinGW.org 的差异的完整列表，请参阅此处。 可从官方仓库安装 mingw-w64-headers 和 mingw-w64-crt 获取。 提供更多库的 AUR 软件包依赖于这些软件包。
    • MinGW：提供对 DirectX 支持有限的 32 位工具链。 它还在线程本地存储和浮点库支持的实现中存在长期存在的缺陷。 它已从官方仓库和 AUR 中移除。
  • 编译器及其运行时库。
    • 对于 C/C++，可以使用 GCC 和 Clang。 要使用 GCC，需要安装 mingw-w64-gcc，因为常规的 gcc 软件包无法使用。 要使用 Clang，只需使用 clang 并指定 `*-w64-mingw32` 平台三元组作为目标。 由于常规的 clang 软件包不包含 Windows 目标的编译器运行时库，因此需要单独编译它们，或使用 mingw-w64-gcc 提供的运行时库。 提供更多库的 AUR 软件包依赖于 mingw-w64-gcc。
    • 对于 Rust，可以使用 mingw-w64-rustAUR。 常规的 rust 软件包未构建为能够为 Windows 交叉编译。
    • 对于 Go，可以直接使用常规的 go 软件包。
  • C/C++ 标准库。 可以使用 mingw-w64-gcc 提供的 libstdc++ 或 LLVM 项目的 libc++。 提供更多库的 AUR 软件包依赖于 libstdc++。
  • 链接器和其他工具。 可以使用 mingw-w64-binutils 提供的 GNU binutils 或 llvm 和 lld 提供的 LLVM/lld。 还有 mingw-w64-toolsAUR 提供一些额外的 Windows 特定的工具。

对于 ix86/x86_64，典型的选择是使用 mingw-w64- 与 GCC/libstdc++ 和 binutils。 因此，这也是遵循软件包命名 mingw-w64-pkgname 的 AUR 软件包所使用的。 本 Wiki 页面的其余部分重点介绍这些软件包。

还有名为 llvm-mingw-w64-pkgname 的 AUR 软件包，它们使用 LLVM/Clang/libc++，除了 i686 和 x86_64 外，还支持 aarch64。 这些软件包依赖于 https://github.com/mstorsjo/llvm-mingw 的构建，并且不使用 Arch Linux 提供的 LLVM/Clang。 只有少数核心软件包存在。

还有由 https://github.com/Martchus/PKGBUILDs 提供的名为 mingw-w64-clang-arch-pkgname 的软件包。 这些软件包使用 Arch Linux 提供的 llvm、lld 和 clang，并且仅在其之上提供 mingw-w64、LLVM 编译器运行时和 libc++。 这些软件包目前仅适用于 aarch64 目标。 它们主要从 mingw-w64-pkgname AUR 软件包通过转换脚本生成，以便能够提供不仅仅是核心工具链，而无需付出太多额外的努力。 到目前为止，已将 100 多个 mingw-w64-pkgname 软件包转换为 mingw-w64-clang-aarch64-pkgname 软件包。 它们尚未上传到 AUR，因为它们是自动生成的，但生成器和二进制仓库可以在上述 GitHub 仓库中找到。

软件包命名

mingw-w64 的软件包应命名为 mingw-w64-pkgname。 如果正在构建软件包的静态变体，请在软件包名称后附加 -static（有关必要情况，请参见下文）。

打包

跨平台软件包的打包可能非常棘手，因为存在许多不同的构建系统和底层怪癖。 请注意以下事项：

  • 始终将 mingw-w64-crt 添加到 depends，除非它依赖于另一个隐式依赖于它的软件包
  • 始终将 mingw-w64-gcc 添加到 makedepends，除非使用 mingw-w64-configureAUR 或 mingw-w64-cmakeAUR
  • 始终将 !strip、staticlibs 和 !buildflags 添加到 options
  • 始终使用原始的 pkgdesc 并在 pkgdesc 的末尾附加 (mingw-w64)
  • 始终使用并遵循官方软件包的原始 pkgver
  • 始终构建 32 位和 64 位版本的库
  • 始终将所有内容放在 /usr/i686-w64-mingw32 和 /usr/x86_64-w64-mingw32 前缀下
  • 始终使用 any 作为架构（除非软件包包含必须在构建系统上运行的可执行文件）
  • 始终构建共享库和静态库
    • 基于 autotools 的项目通常支持一次构建两者，当使用 mingw-w64-configureAUR 时，共享库和静态库都已启用
    • 如果构建系统或项目不支持此功能，请分别构建两者
    • 如果共享构建和静态构建冲突（例如，因为标头或 CMake 配置文件不同），请考虑将静态库安装到 /usr/i686-w64-mingw32/static 和 /usr/x86_64-w64-mingw32/static
    • 对于较大的项目，请考虑创建单独的 -static 软件包
  • 考虑删除不需要的文档 (rm -r $pkgdir/usr/i686-w64-mingw32/share/{doc,info,man}, rm -r $pkgdir/usr/x86_64-w64-mingw32/share/{doc,info,man})
  • 考虑使用 mingw-w64-configureAUR 来使用 configure 脚本进行构建
  • 考虑使用 mingw-w64-cmakeAUR 来使用 CMake 进行构建
  • 考虑使用 mingw-w64-mesonAUR 来使用 Meson 进行构建
  • 考虑使用 mingw-w64-makeAUR 来使用原始 Makefile 进行构建
  • 考虑使用 mingw-w64-qt5-baseAUR 来使用 QMake 进行构建
  • 考虑在 package() 的 for 循环中使用 ${_arch}-strip 显式剥离符号，如下面的 PKGBUILD 示例所示。
    • 考虑使用 find 命令来迭代 $pkgdir，因为并非所有 DLL、静态库或可执行文件都可能位于其适当的位置。
      • 如果二进制文件是 DLL，请使用 ${_arch}-strip --strip-unneeded *.dll
      • 如果二进制文件是静态库，请使用 ${_arch}-strip -g *.a
  • 如果软件包是模块化的（需要某些构建依赖项，但这些依赖项对于最终用户是可选的），请将它们添加到 makedepends 和 optdepends。 如果更新现有软件包，请务必从 depends 中减去它们。 使用示例： mingw-w64-qt6-baseAUR
  • 如果软件包安装了 $pkgdir/usr/${_arch}/bin/*-config 脚本，请将其符号链接到 $pkgdir/usr/bin/${_arch}-*-config
  • 如果软件包使用 autoconf，请为 configure 显式设置 --build="$CHOST" 以解决 autoconf 错误 #108405 或使用 mingw-w64-configureAUR

如上所述，所有文件都应安装到 /usr/i686-w64-mingw32 和 /usr/x86_64-w64-mingw32 中。 具体来说，所有 DLL 都应放入 /usr/*-w64-mingw32/bin 中，因为它们是运行时需要的动态库。 它们对应的 .dll.a 文件应放入 /usr/*-w64-mingw32/lib 中。 请删除 /usr/share 中任何不必要的文档，甚至其他文件。 交叉编译软件包并非供用户使用，而仅供编译器和二进制分发使用，因此您应尝试使其尽可能小。

始终尝试使 mingw-w64 软件包中的 pkgver 与官方 Arch Linux 仓库（而非 testing 仓库）中相应常规软件包的 pkgver 相匹配。 这确保了交叉编译的软件在 Windows 上以完全相同的方式工作，而不会出现任何意外错误。 如果 Arch 中的软件包已过时，通常有充分的理由，您仍然应该遵循 Arch 版本，而不是使用最新的上游版本。 如果相应的原生软件包位于 AUR 中，则无需遵循此版本策略，因为许多 AUR 软件包通常是孤立的或无人维护的。

示例

以下示例将尝试涵盖一些最常见的约定和构建系统。

Autotools

pkgname=mingw-w64-foo
pkgver=1.0
pkgrel=1
pkgdesc="Foo bar (mingw-w64)"
arch=('any')
url="http://www.foo.bar"
license=('GPL')
makedepends=('mingw-w64-configure')
depends=('mingw-w64-crt')
options=('!strip' '!buildflags' 'staticlibs')
source=("http://www.foo.bar/foobar.tar.gz")
sha256sums=('8f32d4617390d1c2d16f26a27ab60d97807b35440d45891fa340fc2648b04406')

_architectures="i686-w64-mingw32 x86_64-w64-mingw32"

build() {
  cd foo-$pkgver
  for _arch in ${_architectures}; do
    mkdir -p build-${_arch} && pushd build-${_arch}
    ${_arch}-configure ..
    make
    popd
  done
}

package() {
  for _arch in ${_architectures}; do
    cd "foo-$pkgver/build-${_arch}"
    make DESTDIR="${pkgdir}" install
    ${_arch}-strip --strip-unneeded "$pkgdir"/usr/${_arch}/bin/*.dll
    ${_arch}-strip -g "$pkgdir"/usr/${_arch}/lib/*.a
  done
}

CMake

pkgname=mingw-w64-foo
pkgver=1.0
pkgrel=1
pkgdesc="Foo bar (mingw-w64)"
arch=('any')
url="http://www.foo.bar"
license=('GPL')
makedepends=('mingw-w64-cmake')
depends=('mingw-w64-crt')
options=('!strip' '!buildflags' 'staticlibs')
source=("http://www.foo.bar/foobar.tar.gz")
sha256sums=('8f32d4617390d1c2d16f26a27ab60d97807b35440d45891fa340fc2648b04406')

_architectures="i686-w64-mingw32 x86_64-w64-mingw32"

build() { 
  cd foo-$pkgver
  for _arch in ${_architectures}; do
    ${_arch}-cmake -B build-${_arch} .
    make -C build-${_arch}
  done
}

package() {
  for _arch in ${_architectures}; do
    cd "foo-$pkgver/build-${_arch}"
    make DESTDIR="${pkgdir}" install
    ${_arch}-strip --strip-unneeded "$pkgdir"/usr/${_arch}/bin/*.dll
    ${_arch}-strip -g "$pkgdir"/usr/${_arch}/lib/*.a
  done
}
Retrieved from "https://wiki.archlinux.org.cn/index.php?title=MinGW_package_guidelines&oldid=825041"