我的平台是x86_64 + Windows 10 + Cygwin。我的编译器是x86_64-w64-mingw32-gcc
.
出于某种原因,我不得不使用选项编译我的程序,如果可能的话-mabi=sysv
,我想避免使用默认选项。-mabi=ms
程序编译成功。但是当它调用类似的库函数时printf
,它会出现段错误。原因是库函数驻留在 中msvcrt.dll
,这可能是使用除-mabi=sysv
.
那么,有没有办法安装-mabi=sysv
在Cygwin中编译的库?
我的平台是x86_64 + Windows 10 + Cygwin。我的编译器是x86_64-w64-mingw32-gcc
.
出于某种原因,我不得不使用选项编译我的程序,如果可能的话-mabi=sysv
,我想避免使用默认选项。-mabi=ms
程序编译成功。但是当它调用类似的库函数时printf
,它会出现段错误。原因是库函数驻留在 中msvcrt.dll
,这可能是使用除-mabi=sysv
.
那么,有没有办法安装-mabi=sysv
在Cygwin中编译的库?
根据您对手写汇编的评论,您似乎亲身体验了汇编实际上是多么不便携,以及为什么历史上需要像 C 这样的更便携的高级语言。
出现崩溃的原因很可能是由于两个 ABI 之间的寄存器使用情况不同。调用函数时,ABI 定义与每个参数关联的寄存器。因此,当您使用一个 ABI 调用库函数时,该库之前已针对不同的 ABI 编译,该库代码将查看其指定的寄存器并可能访问导致未定义行为的内存。
我认为尽管获取库会解决您的问题,但存在误解。想一想你得到了你想要的东西,即针对 System V ABI 编译的 windows C 运行时库。现在,当您的程序调用时,您printf(...)
至少会将您的参数放在正确的寄存器中。但是文本必须打印到控制台,因此必须要求内核介入并使其发生。为了进行该系统调用,将使用 Windows API 库,并且会发生另一个 ABI 不匹配。所以你可以看到这个困境是如何上升到顶部的。您基本上需要针对 System V ABI 编译的完整 Windows 操作系统,或其他形式的兼容层,例如 WINE 的工作方式。
您在这里可能有两个选择。重写程序集以匹配本机 Windows ABI,或研究使用提供完整(但虚拟化)Linux 环境的 WSL。