From: SF/projects/mingw n. l. <min...@li...> - 2011-12-04 17:12:26
|
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 |