#1468 unable to find headers compiling directx

WSL
closed
None
out-of-date
Known_bugs
2013-01-30
2010-09-10
Anonymous
No

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

Discussion

1 2 > >> (Page 1 of 2)

  • Anonymous
    2010-09-10

    Corrects include path in lib/directx/Makefile.in

     
  • 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.

     

  • Anonymous
    2010-09-10

    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.

     
  • Keith Marshall
    Keith Marshall
    2011-03-16

    • milestone: --> 102882
    • status: open --> pending-works-for-me
     
  • Keith Marshall
    Keith Marshall
    2011-03-16

    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.

     
  • Nathan Coulson
    Nathan Coulson
    2011-03-17

    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"

     
  • 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).

     
    • status: pending-works-for-me --> closed-works-for-me
     
  • Keith Marshall
    Keith Marshall
    2011-12-04

    • milestone: 102882 -->
    • status: closed-works-for-me --> open
     
  • Keith Marshall
    Keith Marshall
    2011-12-04

    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.

     
1 2 > >> (Page 1 of 2)