我正在尝试使用 MSYS2 ( msys2-base-i686-20160205.tar.xz) 在 XP 上编译一个项目。包含的文件之一是：
/z/path/to/libA/Include/A/B/String.h
反过来，该文件在其第 34 行中执行：
#include <string.h>
该文件已经存在，例如：
Z:/msys32/mingw32/i686-w64-mingw32/include/string.h
... Z：驱动器也是我的代码的位置。在我的g++编译行上，我-I Z:/msys32/mingw32/i686-w64-mingw32/include首先，在很多包含之后，-I /z/path/to/libA/Include/A/B. 但是，当我尝试编译时，编译失败，与String.h.
因此，我通过添加（“在预处理阶段后停止”）并在命令行-v -E更改为进行了检查，并且可以在结果中看到：-o File.eg++File.e
...
# 34 "Z:/path/to/libA/Include/A/B/String.h" 2
# 1 "Z:/path/to/libA/Include/A/B/string.h" 1
# 35 "Z:/path/to/libA/Include/A/B/String.h" 2
...
据我了解，预处理器来到第 34 行Z:/path/to/libA/Include/A/B/String.h，看到#include <string.h>，开始string.h在当前目录中查找 - 并找到它，即使它不以这样的名称存在！？事实上，如果我从 MSYS2 bashshell 执行：
$ find Z:/path/to/libA/Include/A/B/ -name 'string.h'
...没有返回任何内容（同时String.h找到大写的）；但是，如果我强制使用非大写名称或大写名称的列表：
$ ls -la Z:/path/to/libA/Include/A/B/String.h
-rw-r--r-- 1 User None 2885 May 31 09:45 Z:/path/to/libA/Include/A/B/String.h
$ ls -la Z:/path/to/libA/Include/A/B/string.h
-rw-r--r-- 1 User None 2885 May 31 09:45 Z:/path/to/libA/Include/A/B/string.h
...那么它们都被报告为存在？！
我猜这就是“混淆”g++的原因，因为它被阻止在系统路径的其他地方/中寻找string.h（微小的字母）。因为，我发现Git-windows 区分大小写的文件名没有正确处理，并且：
虽然 NTFS（和一些远程文件系统）支持区分大小写，但从 Windows XP 开始的 NT 内核默认不支持它。相反，您必须调整注册表设置并重新启动。因此，Cygwin 不支持区分大小写，除非您更改该注册表值。
如果你真的想在 Cygwin 中区分大小写，你可以通过将注册表值设置
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive
为 0 来打开它并重新启动机器。
...我这样做了，但我仍然遇到同样的问题；不确定这是否是因为我在 MSYS2（不是 Cygwin）上使用了 MINGW；或者因为像Enable casesensitive behavior with Windows XP and Interix Subsystem 或 SFU这样的资源引用HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Kernel\ObCaseInsensitive（注意，大写）；但是，我已经有了这些键（我只是将其设置为 0，然后重新启动），并且它们带有微小的字母，就像在 cygwin.com 链接中一样。此外，重新启动后测试，这也没有帮助。
虽然如何使 MinGW 对包含的头文件名区分大小写表明这可能无法解决 - 我能做些什么来解决这个问题，并说服从系统位置g++读取string.h？我已经尝试在不同的机器上构建相同的库，Windows 7 或 8 远程桌面，它使用相同的 MingW 版本 - 所以应该可以做一些事情......