#1468 unable to find headers compiling directx


Build Environment:

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


  • Anonymous

    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

    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

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

    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

    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

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

    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.

    • assigned_to: nobody --> keithmarshall
  • 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.

  • Earnie Boyd
    Earnie Boyd

    Copying your comment in the other ticket:
    Comment By: Keith Marshall (keithmarshall)
    Date: 2011-12-04 02:49

    Hmm. That doesn't look quite right.

    I have a big hit list of issues which need addressing, for the build
    systems of both mingwrt ans w32api; maybe I should take a brief rest from
    mingw-get, and fix them? Here's just the tip of the iceberg:--

    1) I'm wondering if we need a --with-mingwrt-srcdir option to w32api's
    configure, complementary to the --with-w32api-srcdir patch I posted
    recently for mingwrt; the mingw case 'EXTRA_INCLUDES =
    -I$(srcdir)/../../mingw/include' surely isn't correct.

    2) In both INCLUDES and EXTRA_INCLUDES, surely those $(srcdir)/...
    references should be resolved relative to $(top_srcdir)

    3) w32api distributes a humongous aclocal.m4 file; not even a single line
    of it is remotely relevant to the package.

    and the list goes on...

  • Earnie Boyd
    Earnie Boyd

    I agree that --with-mingwrt-srcdir should be needed. And I agree that $(top_srcdir) should be used. Could it be that aclocal.m4 as it exists is in a form to make older versions of autoconf work for Cygwin and it doesn't apply today? I haven't looked at it and I'm in the same boat as Chris in understanding autoconf enough to debug much.

  • Keith Marshall
    Keith Marshall

    Okay. I've already made a start, in my local mercurial sandbox, (which conveniently overlays my CVS sandbox). I'll post the patches here, for comment, when ready, and before committing.

    > I agree that --with-mingwrt-srcdir should be needed.

    I'll fomulate it; should be a straightforward adaption of --with-w32api-srcdir.

    > And I agree that $(top_srcdir) should be used.

    I'll address that.

    > Could it be that aclocal.m4 as it exists is in a form to make
    > older versions of autoconf work for Cygwin

    I very much doubt it.

    > and it doesn't apply today?

    I don't think it ever did apply; there is nothing in configure.in which might ever have required it. The code itself looks like an arbitrary copy from gnulib, or some such source; it has Bruno Haible's name all over it. While I have a great deal of respect for Bruno, I cringe when I encounter his autoconf code; it definitely isn't his forte, is usually grossly over engineered, and consequently badly engineered.

    > I haven't looked at it and I'm in the same boat as Chris in
    > understanding autoconf enough to debug much.

    I don't claim to be an expert, but I think I'm fairly competent. I will, however, need some help in understanding the cygwin specific idiosyncrasies; I'll open a mingw-dvlpr thread for that.

  • Keith Marshall
    Keith Marshall

    I've published a copy of my Mercurial sandbox here: http://hg.code.sf.net/u/keithmarshall/w32api/summary

    I believe that the issue represented on this ticket is resolved by the current tip commit on the config-cleanup branch. Please test.

    There is still a packaging issue, in respect of building for cygwin, remaining to be resolved.

  • Earnie Boyd
    Earnie Boyd

    • status: open --> pending
  • Earnie Boyd
    Earnie Boyd


    In light of mingw.org-wsl should this be close?


  • Earnie Boyd
    Earnie Boyd

    • status: pending --> closed-out-of-date
  • Earnie Boyd
    Earnie Boyd

    • labels: w32api (deprecated use WSL) -->
    • status: closed-out-of-date --> closed
    • resolution: --> out-of-date
    • category: --> Known_bugs
    • milestone: --> WSL