> -----Original Message----- > From: wine-devel-boun...@winehq.org [mailto:wine-devel- > boun...@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