要求¶
支持操作系统和处理器是主要需求。由于内容经常变化，你可以从网站上获取此类信息 1 。
FPC 构建过程需要某些工具。虽然这些都是由操作系统提供的，或者是由 FPC 安装，我在这里明确标识它们，以便更容易调试和构建。
主要工具：
ld GNU 链接器。将一堆.o和.a链接在一起形成一个库（.dll或.so）或程序（如 Windows上是.exe，在Unix上无扩展名）
as GNU 汇编程序。将.s或.as文件中的 textform 转换为.o文件。
ar 从.o文件中创建静态库(.a)。用于构建智能链接的静态库。
make GNU make。确定要构建内容的顺序，两者都在目录级别上。在 *BSD 上称为 gmake。
ppc386 或 ppc<处理器>，最好是最新版本。从其他编译器构建是不现实的，而且，据我所知，已经多年没有尝试过了（1.0.x 时）。
前3个可以在 binutils 包中找到，在主流平台上这个版本并不重要，只不要是古董级平台。
在某些平台上存在旧版，如 OpenBSD 打包时，仍以 a.out 做为二进制格式，听说他们在 3.4 版中不使用了。
这取决于你的目标操作系统和 CPU ，因此这些实用程序很少是来源错误的，否则，会使交叉编译变得复杂。
Make 通常与 binutils 来自同一个源，可以单独使用。请参阅下面关于 make 单独使用部分，了解一些常见的注意事项。
从头开始构建的 Windows 用户，应该获取 makew32.zip 和 asldw32.zip（或类似）文件。上一版本的单独子目录中以获取所需的外部工具。
在 Mac OS X/Darwin 下，binutils 和 make 是 Apple 开发工具的一部分，安装 XCode 时会自动安装10.3。Fink (Mac OS X 的开源软件发行版) 对于 FPC 不是必需，你或许需要其他 Unix 库 (如 mysql、ncurses 等) 都是 Fink 的一部分。有传闻，在10.4中，这些工具基于最新的 GNU 版本。
ld GNU 链接器¶
GNU 链接器是构建 FPC 源到可执行文件的最后一步。如上所述，最新版本的链接脚本是构建的先决条件。除了 win32，链接器支持最基础的参数。（这些已经支持2年了）。对于 Win32 平台，构建工具应该是 mingw32，而不是 cygwin。但是，FPC 可以链接到 cygwin 库。
我们可以使用其它链接器，比如 GNU，但这需要重新实现调用链接器的那部分（这个已经完成，如，在 1.0.x 编译器中实现 OpenBSD 和 Darwin’s mach-O LD 2.0+版中的 a.out）。
请记住，汇编程序和链接程序之间的关联文件是 .o文件。链接器更改为不同格式的需要不同汇编程序。相反，不同的汇编程序需要调整 FPC 汇编代码。
如果你的平台不是主流的 *nix 或 windows，尝试查找支持 ld-sections 参数的链接器。新的智能链接将基于 LD 参数。
从 FPC2.1.1 开始，对于某些使用 -Xi 的平台，编译器还有一个内部链接器，它速度更快，占用更少的内存，特别是在使用智能链接 2 时，在编写本文时，这个内部链接器已支持 Windows 平台（PE）。
as GNU汇编程序¶
汇编器必须是相对较新的 GNU (G)AS，旧的 X86 GNU 汇编程序可能有隐藏的问题， 当使用 gcc 时不一定会触发。由于 GNU AS 是一个典型的后端汇编器，对早些的处理模式和操作码，如 gcc 没有支持这些模式和操作码就会出现问题。
像 OpenBSD 3.x 系列，只需要将软件包目录的程序替换掉，FPC 就可以构建，但在打包汇编程序时失败了。一个较新的版本不会出现此问题，因为它们可以支持更新的 x86指令（SSE2，SSE3）。
在某些平台上（win32和x86 elf），fpc 有一个内部汇编程序，可以避免性能问题。这个内部汇编程序用 fpc 术语称为 binwriter。binwriter 不仅仅是一个纯粹的汇编程序，它还可以直接编写静态库（*.a）。虽然普通汇编也能实现，binwriter 用于解决在智能链接时出现的性能问题。
FPC 还可以生成 TSM、NASM、MASM 和 WASM (watcom) 格式的代码。但这些未经过严格测试，因此，在使用时会所不同。
ar GNU 归档程序¶
归档程序将目标代码（.o）创建为归档（.a）文件。目的在于减少链接过程和光盘上的文件数。归档文件通过称为静态库，因为它们包含静态链接代码与动态代码.so（或.dll)类似。（一个 .dll 和 .so 文件可以包含多个 .o文件）。GNU 链接器可以直接访问 .a 库。
AR 有时会有问题，命令行中会向编译器传递所有参数。如智能链接，参数将会很多，这将会大于操作系统允许的参数数量（64k参数太少，128k可以）。
make GNU make¶
Free Pascal 构建过程使用由 FPCmake 生成的普通 （GNU make）make 文件。FPCmake 从全局模板生成 Makefile，并在每个目录中生成 Makefile.fpc。这个 Makefile.fpc 是一个简单的 INI 文件，它扩展和参数化全局模板 3 。计划将来使用自有版本替换掉 MAKE 实用程序，但这些仍处于初期阶段。目前的系统很好，很灵活。
目前使用的 make 是 GNU make，几乎适用于所有平台。下面列出了一些平台奇怪之处：
Linux 唯一没有太多奇怪之处。在所有 Unix 中，Linux 使用 GNU 工具相对较多，从最初 unix 派生出工具也更少。如果 Linux 上有 make 或 make-package，它很可能是 GNU。
*BSD 默认 make 是一个 pmake 变种，与 GNU 略有不同。FPC 使用的 makefile 模板与 pmake 不兼容。（注意，注意）GNU make 可以从软件包目录安装，通常是 devel/gmake。不要忘记将 ports-$PREFIX (/usr/local/bin， /usr/pkg/bin 等)的 bin 目录放入环境变量中，并用 gmake 代替 make。在实践中，这不是一个大问题，因为 gmake 通常是 BSD 系统许多开发包的依赖。
BeOS 我安装时（BeOS 5个人版），binutils 和 GNU make 都附带了开发套件。
OS/2 这个，我真的不知道。有 EMX 和本机版本，当然还有 DOS。Afaik FPC 以前是基于 EMX 的，但目前正朝着原生发展。我自己得研究一下这个问题。
Dos/Go32V2 使用 DJGPP Go32V2 实用程序。这是因为 FPC 使用 go32v2 扩展器，为了方便扩展器安全的嵌套程序，所有扩展器都必须相同。包括utils :-)
Netware 没想法，我从未见过在上面运行。
win32/win64 使用 mingw 配置，最好使用最新发布的 FPC 版本。见下文。
winCE 我的经验仅限于 CE 做为交叉编译目标。如有 NAS 设备，可以在基于 WinCE 的主机上引导 FPC。
Mac OS X 附带Apple 开始工具（在10.3上随 XCode 一起安装）。使用通用的 Unix 库，如 mysql，ncurses，postgresql 等可能需要 FINK。
win32 上的情况经常让人困惑。这主要是因为至少有三种以上的程序（ar、ld、as、make）可以在 Windows 上运行。任何组合（一类程序，另一类程序）也可能导致不可预测的结果。不管怎样，这3个是：
Mingw （有时称为 mingw32）就是目前要使用的。Win32 原生工具，真正 Win32 感觉。（路径中驱动器和反斜杠等）最好使用与 FPC 发行版一起发行的版本，因为它们可能包含关键的 FPC 补丁。例如，mingw 工具只搜索大写的 PATH 变量，在基于 NT 的Windows 版本中，常见的拼写是类似 Path 的路径。有关更多信息，请参阅 FPC 网站上 FAQ 的 win32 部分。
Cygwin 为 Unix 提供最大的兼容性，可以看作是 Unix 兼容层。然而，FPC 在 Windows 上是原生的，FPC 确实可以使用当前安装的 Cygwin 进行编译，但生成的编译器不是 cygwin 程序。此外，cygwin 程序需要正确 cygwin1.dll 的版本。注意：FPC可以链接到 cygwin，但不需要它进行操作（textmode IDE 除外）。最近，Cygwin 改进了原生路径支持，如果路径完全正确。Mingw 还是更好，cygwin 可用于紧急操作。
go32v2 Go32v2 是基于 DOS 的，并且通过 Windows 的 dos 兼容系统使用，不要与win32 编译器一起使用，就像在 Linux 上通过 Wine 使用 win32 工具 :-)
我在 win32 上遇到的一个常见问题是将 cygwin bin 目录放在 win32 搜索路径中。mingw make.exe 和cygwin shell，尝试用它执行某些程序。不过，Cygwin 最近有很大改进，现在看来这又起作用了，如果所有东西都位于一个驱动器上（你可以用 cygwin 和fpc 命令行编译器重新编译 fpc）。
请注意，其它开发工具 (Borland、Microsoft、java) 也可以打包 make。建议始终将 FPC 作为 PATH 中的第一个目录。
由于 fpc makefile 并行编译有了新的进展，强烈建议从 FPC2.1.1（2007年1月以后）起使用 make 3.80。具有双核和最新源的 Unix 用户尝鲜请使用 make -j 2。
FPC自身 ppc386，ppcppc，ppcsparc，fpc¶
在 Pascal 方言中，Free Pascal 主要由自己编写。因此这对构建有些影响。
FPC 的正常构建只能使用 FPC 作为编译器。
在 makefile 不被支持后，在某些情况下，Delphi 构建会持续一段时间，这需要些技巧，Delphi 兼容性一直被忽视，因为有太多 BUG，并且保持可编译是一个问题。
在1.9.4和1.9.6之间的大部分 Delphi 解决方法已被移除。D2005 上未进行过测试。Delphi 在可用性方面很棒，但作为编译器可能会失败，由于 Delphi 的 BUG，使用FPC 会更容易。
对于1.0.x及更早版本，可以从 TP 构建。由于编译器是很复杂的程序，Delphi 对 TP的单一数据集限制很严重，因此1.1.x 后将无法使用 Delphi 编译。
GNU GPC 或 p2c 是不能构建的。他们的 TP 模式与 TP/BP 不兼容，FPC 1.1.x及更高版本需要 Delphi 兼容性。
通过 VP 构建可能在理论上是可行的，至少对于1.0.x是可以做到的。这些从未经过测试。使用 FPC 可以在几乎所有平台上进行重新编译，并减少BUG。
如何选择应该在支持文档中而不是在这里 4。
实际上有一个重要的缺点：你需要使用 FPC 来构建 FPC ；和一个优势：与安装工作相比，FPC 通常有更少的依赖来构建。GCC 构建时，需要一个工具来构建 FPC，甚至不需要安装。（在不附带的编译工具的平台上，你需要 GUN 构建，参见上面段落），并且基本上没有库依赖。有了内部链接器，随着时间的推移，GNU 工具的依赖也可能消失，允许单个编译器完整构建整个 FPC/Lazarus 项目。
你需要使用 ppc<处理器>文件来构建普通快照，ppc386 代表 x86，ppcppc 代表 PowerPC，ppcsparc 代表 Sun Sparc V8 系统，ppcx64 代表 x86_64（64-bit x86）等等。
到目前为止，这些文件静态链接的。所以，只有一个 Linux 编译器，一个 FreeBSD 编译器等。内核、库、分发版本并不重要。（除了极端情况下内核有大的变动，如 Linux 1.0. x 到 2.0. x）
对于同处理器不同操作系统的交叉构建，你不需要特殊的交叉编译器。只有在交叉构建不同的处理器时才需要。
除此之外，还有 fpc 可执行文件。这是系统上所有 ppc <cpu> 编译器的常见工具，编译当前架构的编译器和其余架构的编译器。你可以使用这个文件，并使用 -P 参数。因此：
fpc -Ppowerpc compileme.pp
如果一切配置正确，将使用 PowerPC（ppcppc）编译器编译 compileme.pp。稍后会介绍:-)
fpc 可执行文件可以设置编译器的版本：
fpc -V1.0 compileme.pp
将使用-1.0 su 编译默认编译器（ppc<当前处理器>）。与 -P 结合使用，fpc -Ppowerpc -V1.0 将尝试运行一个二进制 pppnc-1.0 作为真正的编译器。特别是在 Unix 上，这很好使用，只要几个符号链接就可以轻松的切换版本。
结合创建的 fpc.cfg 文件，可以构建强大的交叉编译系统，自动选择正确的目标。我们稍后会谈到。