Possible wine bug concerning the case of the DbgHelp.h header filename

[Gregory Turner]

> -----Original Message-----
> From: wine-devel-bounces at winehq.org [mailto:wine-devel-
> bounces at winehq.org] On Behalf Of Paul Chitescu
> Sent: Wednesday, June 12, 2013 2:37 AM
> To: wine-devel at 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