On Tue, 2015-04-28 at 09:25 +0200, Ruben Van Boxem wrote: > 2015-04-28 8:36 GMT+02:00 Pavel <[email protected]>: > On Tue, 2015-04-28 at 08:08 +0200, Christer Solskogen wrote: > > On 27.04.2015 20:16, LRN wrote: > > > > > At a glance it looks like SDL_render_d3d11.c declares and > defines > > > IID_IDXGIFactory2, and mingw's dxgi1_2.h declares > IID_IDXGIFactory2 as well > > > (and defines it in some library, likely libuuid.a). > > > > > > Apparently, SDL2 was written against a SDK (likely > mingw.org) that has no > > > IID_IDXGIFactory2. > > > > > > The fix is to remove > > > static const GUID IID_IDXGIFactory2 = { 0x50c83a1c, > 0xe072, 0x4c48, { 0x87, > > > 0xb0, 0x36, 0x30, 0xfa, 0x36, 0xa6, 0xd0 } }; > > > from SDL2 (or at least ifdef it out based on some macro > from dxgi1_2.h). > > > > > > At a glance, anyway. > > > > > > > Okay? Compiling SDL2 using v3.x (git) works just fine. > > > > This is nothing surprising. The UIDs and interface definitions > are > constantly added to the MinGW source (includes). For example, > I have an > application using MSXML. There were no definitions for MSXML > interfaces > so I had to add my own. It compiled fine with MinGW 3.x, but > the MSXML > UIDs and interfaces has been added in MinGW 4.x. So I had to > remove my > definitions in order to compile my project with MinGW 4.x. > This is > called "progress" or "evolution" :-) > > > This progress would go faster if *all* upstream projects would just > contribute these changes back instead of hiding them in their headers. > I know a lot of them are already doing this, and it may just be a > remnant of the stale MinGW.org developer policy to accepting and > implementing such changes. Here's me hoping for a brighter future :p > > /rant > Well, I am just a (happy) user of MinGW64, but I believe this is not a problem of upstream projects. This is a general problem of COM objects available in the OS. There are plenty of COM libraries delivered by Windows and other dozens of those delivered by installed applications. It is neither possible nor desirable to deliver all the definitions with the compiler. It would be much better to provide a generic tool capable of reading type libraries and generating C++ headers for them. I have developed such a tool many years ago. Unfortunately it is written in Delphi, so it would be a shame to share the source code. But maybe I can consider rewriting it into C++.
Pavel ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
