To see the problem, you need to compare the content of w32api-3.15-1-mingw32-src.tar.lzma and w32api-3.15-1-mingw32-dev.tar.lzma - upstream forgot to include gdiplus headers in src tarball.
3.15 isnt in the tree anymore
Well, that's not really a solution - IIRC, that was first release containing gdiplus headers.
On an annoying note: in the meanwhile 3.17 was released and is broken in the same way.
you're going to have to be a little more specific. seems to me it has some gdiplus files as `tar tf | grep gdiplus -c` is not 0.
Well, just compare the content of those tarballs. In the dev, you have lib/ containing that dll linking glue Gentoo builds in mingw-runtime and include/ with headers Now, in src tarball you have include/gdiplus.h *header*, while in dev tarball there's that header + include/gdiplus/ dir with a lot more headers. The content of include/gdiplus.h is a single line: #include "gdiplus/gdiplus.h" which redirects to the missing dir.
OK, correction, this particular glue does belong to w32api too, but the rest stands.
if you knew about this issue and reported it against 3.15, but it's still broken in 3.17, did you not report it to the upstream project ?
Let's just say I've got *issues* with non-anonymous SourceForge services, bugtracker in particular. Not only it doesn't work for me in Firefox (even if that because of one of the extensions, no other forum/bugzilla is giving me such problems), but most of the bugs I reported there (granted, of varying validity/quality) were getting closed in a way, that prevented me from adding any explanation/clarification.
so the answer is "no, it hasnt been reported to them" ?
and less than 24hrs after reporting, it's fixed upstream :P