-----Original Message----- From: wine-devel-bounces@winehq.org [mailto:wine-devel- bounces@winehq.org] On Behalf Of Paul Chitescu Sent: Wednesday, June 12, 2013 2:37 AM To: wine-devel@winehq.org Subject: Re: Possible wine bug concerning the case of the DbgHelp.h header filename On Wednesday 12 June 2013 02:49:26 am Alan W. Irwin wrote:
[snip]
For what it is worth, I did a google search for <windows dbghelp.h> and most of the hits were for DbgHelp.h rather than dbghelp.h so I can understand why the ninja developers used
#include<DbgHelp.h>
rather than the lower-case version of that name.
If the wine developers here decide this is definitely a wine issue, I am willing to write up the bug report on your bugtracker so this issue doesn't get lost. A search there for <header case filename> did not turn up anything relevant.
Hi!
The Platform SDK creates DbgHelp.h however it shouldn't matter for Windows programs as they are case insensitive.
It's worth mentioning that the case insensitivity of Win32 is configurable (see http://support.microsoft.com/kb/929110) , and that NTFS itself is technically case-sensitive (see http://support.microsoft.com/kb/100625).
The problem here is that MinGW somehow operates case sensitive so raise a bug for that.
See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf p. 163, ยง6.10.2. Whether or not that's a bug is purely a subjective matter. That being the case, I, like you, would prefer that MinGW gcc considered DbgHelp.h to match dbghelp.h here. I vaguely recall something to the effect that gcc determines whether the underlying system has inode stability and, only if the inode stability is lacking, will look for headers case-insensitively...
I do happen to know from experience that as of a few days ago, a cross-compiling gcc trunk build with a linux host and a *-w64-mingw64 target will treat headers case-insensitively. I wouldn't be at all surprised if the difference is detected by autotools at build time, and that, therefore, two native mingw->mingw gcc compilers might behave differently, if one was built using a *-linux-* -> *-mingw* cross-compiler whereas the other was built on msys using a native mingw->mingw bootstrap... if that's right, it does kind of seem like a bug (or, at best, an unfortunate feature).
-gmt