MSYS2 case sensitivity and includes on XP?
<p>I am trying to compile a project on XP with MSYS2 (<code>msys2-base-i686-20160205.tar.xz</code>). One of the files included is like:</p>

<pre><code>/z/path/to/libA/Include/A/B/String.h
</code></pre>

<p>This file, in turn, does in its line 34:</p>

<pre><code>#include &lt;string.h&gt;
</code></pre>

<p>This file already exists as, say:</p>

<pre><code>Z:/msys32/mingw32/i686-w64-mingw32/include/string.h
</code></pre>

<p>... where the Z: drive is also the location of my code. On my <code>g++</code> compile line, I have <code>-I Z:/msys32/mingw32/i686-w64-mingw32/include</code> first, and after a lot of includes, <code>-I /z/path/to/libA/Include/A/B</code>. However, when I try to compile, the compilation fails, related to <code>String.h</code>. </p>

<p>So, I inspected a bit by adding <code>-v -E</code> (to "stop after the preprocessing stage") and changing to <code>-o File.e</code> at the <code>g++</code> command line, and can see this in the resulting <code>File.e</code>:</p>

<pre><code>...
# 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
...
</code></pre>

<p>As I understand this, the preprocessor comes to line 34 of <code>Z:/path/to/libA/Include/A/B/String.h</code>, sees the <code>#include &lt;string.h&gt;</code>, starts looking for <code>string.h</code> at the current directory - and finds it, even if it doesn't exist under such name!? Indeed, if I do from the MSYS2 <code>bash</code> shell:</p>

<pre><code>$ find Z:/path/to/libA/Include/A/B/ -name 'string.h'
</code></pre>

<p>... nothing is returned (while <code>String.h</code>, capitalized, is found); however, if I force a list with either the non-capitalized or the capitalized name:</p>

<pre><code>$ 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
</code></pre>

<p>... then they are both reported as existing?! </p>

<p>I'm guessing this is what "confuses" <code>g++</code>, in the sense of it being prevented from looking for <code>string.h</code> (miniscule letters) elsewhere/in the system path. Since, I've found <a href="https://stackoverflow.com/questions/2528589/git-windows-case-sensitive-file-names-not-handled-properly">Git-windows case sensitive file names not handled properly</a> and:</p>

<ul>
<li><a href="https://cygwin.com/cygwin-ug-net/using-specialnames.html" rel="nofollow noreferrer">https://cygwin.com/cygwin-ug-net/using-specialnames.html</a></li>
</ul>

<blockquote>
  <p>While NTFS (and some remote filesystems) support case-sensitivity, the NT kernel starting with Windows XP does not support it by default. Rather, you have to tweak a registry setting and reboot. For that reason, case-sensitivity can not be supported by Cygwin, unless you change that registry value.<br>
  If you really want case-sensitivity in Cygwin, you can switch it on by setting the registry value<br>
  <code>HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive</code><br>
  to 0 and reboot the machine.</p>
</blockquote>

<p>... and I did this, but I still have the same problem; not sure if this is because I use MINGW on MSYS2 (not Cygwin); or because resources like <a href="https://support.microsoft.com/en-us/kb/817921" rel="nofollow noreferrer">Enable case sensitive behavior with Windows XP and Interix Subsystem or SFU</a> refer to <code>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Kernel\ObCaseInsensitive</code> (note, capitalized); however, I already had these keys (I just set it to 0, and rebooted), and they were with miniscule letters, like in the cygwin.com link. Also, tested after reboot, this didn't help either.</p>

<p>While <a href="https://stackoverflow.com/questions/4241864/how-can-i-make-mingw-case-sensitive-for-included-header-file-names">How can I make MinGW case-sensitive for included header file names</a> indicates this may not be possible to solve - is there anything I can do to resolve this problem, and to persuade <code>g++</code> to read the <code>string.h</code> from the system location? I've tried building the same library on a different machine, Windows 7 or 8 remote desktop, with the same MingW version where it worked - so something should be possible to do...</p>