Menu
▾
▴
[MinGW-notify] [ mingw-Bugs-3063296 ] unable to find headers compiling directx
|
From: SF/projects/mingw n. l. <min...@li...> - 2012-10-19 16:31:28
|
Bugs item #3063296, was opened at 2010-09-09 23:15 Message generated for change (Settings changed) made by earnie 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 (deprecated use WSL) Group: None >Status: Closed >Resolution: Out of Date 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: Earnie Boyd (earnie) Date: 2012-10-17 07:25 Message: Keith, In light of mingw.org-wsl should this be close? Earnie ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2012-01-01 08:35 Message: 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. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-12-05 14:50 Message: 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. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2011-12-05 14:03 Message: 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. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2011-12-05 13:58 Message: Copying your comment in the other ticket: Comment By: Keith Marshall (keithmarshall) Date: 2011-12-04 02:49 Message: 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... ---------------------------------------------------------------------- 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 |
