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

2013-06-13 Thread Gregory Turner
 -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
 
 #includeDbgHelp.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






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

2013-06-12 Thread Henri Verbeet
On 12 June 2013 01:49, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
 I successfully built the ultra-fast ninja build tool on Wine using the
 MinGW g++ compiler.  To achieve that success I had to deal with a
 small number of issues including
  one wine/ninja header name inconsistency which is that DbgHelp.h
 (#included by the ninja code) has a lower-case name (dbghelp.h) on
 wine, and the MinGW suite of compilers is sensitive to the case of
 header file names.  I worked around this issue with the following
 symlink

 /home/wine/wine_build/install-git/include/wine/windows/DbgHelp.h -
 dbghelp.h

 where /home/wine/wine_build/install-git is my install prefix for
 my wine-git build.

 Is Wine following the correct Windows naming convention for this
 header?

There's no such thing, at least wrt. case; Windows is case
insensitive. Wine just uses lower case, and for the most part that's
also the C / Unix convention, although there are certainly exceptions.
Typically you'd just change your source (Ninja in this case) to
consistently use lower case, instead of creating symlinks.




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

2013-06-12 Thread Paul Chitescu
On Wednesday 12 June 2013 02:49:26 am Alan W. Irwin wrote:
 I successfully built the ultra-fast ninja build tool on Wine using the
 MinGW g++ compiler.  To achieve that success I had to deal with a
 small number of issues including
   one wine/ninja header name inconsistency which is that DbgHelp.h
 (#included by the ninja code) has a lower-case name (dbghelp.h) on
 wine, and the MinGW suite of compilers is sensitive to the case of
 header file names.  I worked around this issue with the following
 symlink

 /home/wine/wine_build/install-git/include/wine/windows/DbgHelp.h -
 dbghelp.h

 where /home/wine/wine_build/install-git is my install prefix for
 my wine-git build.

 Is Wine following the correct Windows naming convention for this
 header?

 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

 #includeDbgHelp.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.

 Alan

Hi!

The Platform SDK creates DbgHelp.h however it shouldn't matter for Windows 
programs as they are case insensitive.

The problem here is that MinGW somehow operates case sensitive so raise a bug 
for that.

Paul




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

2013-06-12 Thread Alan W. Irwin

On 2013-06-12 12:37+0300 Paul Chitescu wrote:


Hi!

The Platform SDK creates DbgHelp.h however it shouldn't matter for Windows
programs as they are case insensitive.

The problem here is that MinGW somehow operates case sensitive so raise a bug
for that.


You are right.  So I put together a simple example demonstrating this
MinGW issue and it worked fine indicating that MinGW has no such bug and
can deal with these case issues with no problem.

There must have been some other issue with my complicated example, and
my apologies to you and Henri for the noise I generated about this
issue, but also my thanks to you guys for clarifying the issue.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__