[MinGW-notify] [ mingw-Bugs-3063296 ] unable to find headers compiling directx

[SF/projects/mingw n. l. <min...@li...>]

Bugs item #3063296, was opened at 2010-09-09 23:15
Message generated for change (Comment added) made by ir0nh34d
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3063296&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
>Assigned to: Keith Marshall (keithmarshall)
Summary: unable to find headers compiling directx

Initial Comment:
Build Environment:
--linux, 

Tools:
--Binutils
--gcc (Only compiled w/ make all-gcc and make install-gcc)

When compiling w32api, I received the following err

i686-pc-mingw32-gcc -c -O2 -g -I./../include -I./../include/directx -I./../../mingw/include -o dinput_joy.o dinput_joy.c
In file included from dinput_joy.c:13:0:
dinput_private.h:16:21: fatal error: windows.h: No such file or directory
compilation terminated.
make[2]: *** [dinput_joy.o] Error 1
make[2]: Leaving directory `/mnt/raid5/book/other/mingw32/tmp/w32api-3.14-mingw32/lib/directx'

I was able to resolve it with the following patch, which corrects the locations for the respected header files

----------------------------------------------------------------------

>Comment By: Chris Sutcliffe (ir0nh34d)
Date: 2011-12-04 09:12

Message:
Hi Keith,

I'd appreciate it if you could run with this issue as well as the other
related issue.  autotools are not my strong suit, so I could definitely do
with the help.

Thank you.

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-12-04 07:11

Message:
I'm reopening this. 
https://sourceforge.net/tracker/?func=detail&aid=3447137&group_id=2435&atid=302435
is a duplicate of this issue; it presents another (different) patch.  I
guess neither is entirely correct, so let's investigate further, and fix it
properly.

Chris, feel free to reassign it to me, if you'd prefer me to follow it up;
the issue appears, to me, to be that the include path is resolved via
$(srcdir), where $(top_srcdir) should have been the preferred choice.

----------------------------------------------------------------------

Comment By: SourceForge Robot (sf-robot)
Date: 2011-04-15 05:20

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 30 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Nathan Coulson (conathan)
Date: 2011-03-16 20:53

Message:
Nathan Coulson,  (when I filed the bug, I was trying to link my gmail
account to my sf profile.  not quite the results I wanted)

http://nathancoulson.com/proj_cross_mingw.shtml documents how my toolchain
is built (not perfect, unfortunately.  still have parts that were from 5
yrs ago in there)

the file, windows.h that is not found when compiling win32api,  is actually
in the win32api tarballs.

srcdir at the time of failure, is w32api-3.14-mingw32/lib/directx

windows.h is in w32api-3.14-mingw32/include/windows.h

by default, it is searching in $(srcdir)/../include,   which resolves into
w32api-3.14-mingw32/lib/include instead of 32api-3.14-mingw32/include

I see why it works on the script,  you copy the include files in w32api
before you compile & install w32api.
      $RUN cp -r w32api-*/include "$INSTALL_DIR" || die $? \
            "$unrecoverable installing w32api headers"

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-03-16 05:17

Message:
I've never had the slightest problem building w32api, (nor any other
component of the cross-hosted tool chain), when building the Linux hosted
mingw32 tools I use.

I see absolutely no reason why we should consider this patch further.  I
suggest that you review your build procedure, and compare it with the
method we use, as managed by the cross-compiler build scripts we offer on
our download page.  These may need updating, but fundamentally, the build
method does work.

BTW, who are you?  Masquerading as https://www.google.com/accounts is an
excellent strategy for getting your submissions consigned to the bit
bucket.  Please identify yourself, and submit using a proper SF account
name.

----------------------------------------------------------------------

Comment By: https://www.google.com/accounts ()
Date: 2010-09-10 15:43

Message:
windows.h is found in the include directory in the w32api.

the Makefile.in in lib/directx is looking in ../include, when it should be
../../include.  Correcting the Makefile.in file, and rerunning ./configure
allowed it to work.

----------------------------------------------------------------------

Comment By: Chris Sutcliffe (ir0nh34d)
Date: 2010-09-10 04:24

Message:
According to the error message, it's windows.h that the dinput_private.h
can't find.  Make sure that windows.h is in one of your include paths.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3063296&group_id=2435