我一直在寻找Cygwin / Mingw / lcc ，我喜欢能够编译我的窗口上的Perl本地C扩展（最好是在cygwin下），然后在Solaris和HP unix上运行它们，而不需要大惊小怪，这可能吗？
这一切都源于我原来的perl跨平台的问题在这里 。
交叉编译器很难设置并正常工作。
考虑一下（NetBSD的人）必须投入大量的工作才能使交叉编译工作，而且他们运行的是相同的操作系统，只是不同的体系结构。
至少，你必须把所有其他操作系统的头文件复制到Windows，并为目标操作系统/体系结构获得交叉编译器，链接器等。
此外，这可能是不可能的 – perl和共享库可能会编译一个本地/非gcc编译器，根本不会在Windows上可用。
（这是一个非常古老的问题，但缺少一些有用的信息 – 我亲自为Solaris（SPARC＆x86），AIX，HP-UX和Linux（x86，x64）完成了这个工作。
获得C ++交叉编译比直C更困难
不支持HP-UX 32位PA-RISC，因为它使用SOM格式而不是ELF，而binutils不支持SOM（也可能不会）。 换句话说，你只能交叉编译64位的PA-RISC。 （需要PA-RISC 2.0芯片。）
如果可以的话，我会用mingw代替cygwin。 Cygwin引入了很多文件权限头痛和cygwin1.dll依赖关系，可能会很麻烦。 如果可能的话，建立在Linux上。 一切都会更快，因为你所运行的所有工具和脚本都是为exec和stat是快速操作的环境而设计的。 Windows + NTFS不是那个环境。
从crosstools脚本开始，但准备在此上花费大量时间。
首先尝试使用最新的gcc / binutuils，但如果你不能解决问题，可以尝试退回到旧的软件包。 例如，对于Power3（AIX）gcc 4.x系列交叉编译器生成错误的代码，3.x是好的。
当复制本机库和头文件时，确保你从可能运行的最老的机器上复制。 复制一个新的libc意味着你的代码将不会运行在任何旧版libc的机器上。
在复制本机库和头文件时，可能需要'tar -h'将符号链接转换为实际的文件，同样要注意在Solaris上，一些必需的crt目标文件被埋在cc目录中，而不是在/ usr / lib下
我同意道格拉斯的观点，开发一个交叉编译器非常困难。 这通常是你最后的选择。 如果你是引导捆绑，或者为嵌入式设备制作二进制文件，那么经常交叉编译是你唯一的选择。 在考虑交叉编译之前，你应该可以在Cygwin下编译你自己的gcc。 为了交叉编译，你需要构建一个在Windows下运行的gcc，但是它会为你的执行平台创建二进制文件。 可以在这里找到这样做的示例说明。
也许你想交叉编译，因为你没有root和/或无法在你的目标平台上编译。 例如，我有一个运行Redhat Linux的托管服务提供商。 我可以运行Perl CGI脚本和相关的模块，但是我无法在目标机器上编译，而且我构建的库必须存在于我自己的目录中。
为了解决这个问题，我本可以尝试为我的目标平台进行交叉编译，但是我决定在Windows上的一个虚拟机中设置一个类似的主机。 在Cygwin中，你可以创建一个ssh到你的虚拟机中的脚本，复制你的源代码，并完成一个完整的配置/构建。 最后一步是将二进制工件部署到我的托管系统上。
我已经成功地在Solaris上运行Solaris 10和Open Solaris。 不幸的是，在虚拟机下运行HPUX可能会比较困难。
你为什么不读一下“Grand Unified Builder”（ http://lilypond.org/gub/和http://valentin.villenave.info/TheLilyPond-Report-11 （第4节））
我不知道它是如何工作的，但是GUB允许Lilypond的开发人员在Linux上编译大约11个平台。
在Windows上编译，然后使用Wine在任何* nix上运行它们。 它大部分时间运作良好。
不，这在二进制级别是不可能的。 各种操作系统和CPU之间在二进制级别上有很多不同之处。
但是你可以做的是使你的C扩展源兼容，以便它可以编译到不同的平台。 C被设计成“便携式汇编语言”。 只要你坚持跨平台的程序，那么他们通常会一样的工作。 您仍然需要测试，因为可能存在特定平台上的错误。
这是无法完成的……但是在Solaris或HP下重新编译代码有多麻烦？