From: factory AT labyrinth DOT net DOT au (Factory) Subject: Re: DirectX and mingw.. 25 Apr 1998 23:42:43 -0700 Message-ID: <3.0.3.32.19980426115941.00862350.cygnus.gnu-win32@mail.labyrinth.net.au> References: <199804250325 DOT UAA23266 AT mail1 DOT teleport DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: gnu-win32 AT cygnus DOT com At 20:27 24/04/98 -0800, wrote: > Problem is that the Directx available from the URL you referenced is set >up for Cygwin32 b17 or b18 and doesn't link without Cygwin32.dll being >somewhere on the path. Erm I'm assuming you are referring to run-time linking as oppsed to compile-time linking, which works fine. > Fortunately, the header files included for ddraw.h do work under >Cygwin32. Unfortunately, you have to replace your ddraw.dll file on >your computer with the ddraw.dll included as part of the DirectX >stuff you downloaded. Erm the stuff I downloaded doesn't have a new .dll, only a .h file and a library file (libddraw.a). > Fortunately, this is rather simple. Unfortunately, in order to get >Mingw32 to work with the ddraw.h stuff, you must configure your system to >support switching between Cygwin32 and Mingw32 and set your development >environment to default to the cygwin32 gcc for all of your DirectX compile >needs thus negating any positive effect you may have received by >installing and using Mingw32. Agreed, this is a Bad Thing (tm). :) > Mingw32 and Cygwin32, out-of-the-box, do not as you proabably already >know, support DirectX in any form. Yes, and DirectX doesn't seem to support anything other than VC.. funny that. > I suppose that if you were ambitious enough and had an abundance of time >on your hands, you _could_ probably convert every single DirectX (ver 5 or >lower) API related header to something that Mingw32 could understand and >use. Mingw apparantly doesn't have much of a problem with the .h files from directx, only a few of the unnamed unions need to be changed. Going by what someone else has said here. > Another possibility is that you could use a separate development >environment for your C and C++ programs. I only suggest this because >there is a non-Gnu C compiler that actually did convert all of the MS >header files that it came with into something understandable by a non-Gnu >compiler. Whether those files (libs and obj) may be properly linked >via "ld" or any version of the Gnu linker remains to be seen. > It is also rumored that the aforementioned non-Gnu compiler can actually >convert all of the most recent MS Platform SDK headers into something that >can be read by the aforementioned non-Gnu compiler. Hmm I'm assuming that the rumours are about lcc :), but I really am a bit of C++ junkie.. :) And that would be only useful if I actually had the SDK, which would require sending dollars to MS, since they have decided that letting ppl download the sdk off their site is not cost effective.. hmm... Incidentally someone else mailed me about the problem and he believes the problem is similar to a loader bug in egcs, hmm guess I'll have to wait for b19 ported, it might fix my problem. - Factory (.sig under reconstruction) - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".