GNOME Bugzilla – Bug 593068
Disarray in directsoundsrc/directdrawsink
Last modified: 2009-08-26 09:49:11 UTC
Created attachment 141681 [details] [review] Direct* stuff fixes 1) Checks for dsound.h (which is included from DirectX SDK) without using DIRECTSOUND_CFLAGS (which specifies -I path for DirectX SDK) 2) Uses separate DIRECTSOUND_CFLAGS and DIRECTDRAW_CFLAGS with the same contents (-I path for DirectX SDK) 3) There are unused variable and label in directdrawsink.c Patch is attached: 1) Use custom compile/link check for directsound (instead of generic compile and generic link check), with proper include path 2) Use one DIRECTX_CFLAGS for both plugins 3) Remove unused variable and unused label from directdrawsink.c
Hi, "3) Remove unused variable and unused label from directdrawsink.c" --- configure.ac | 55 ++++++++++++++++++++++++++--------- sys/directdraw/Makefile.am | 24 +++++++------- sys/directsound/Makefile.am | 24 +++++++------- sys/directsound/gstdirectsoundsrc.c | 8 ----- 4 files changed, 65 insertions(+), 46 deletions(-) " According to your patch, I think this is directsoundsrc.c and not directdrawsink.c ? And yes there is no "dsound.h" and "ddraw.h" in the official mingw-win32-api package (see comment #22) http://bugzilla.gnome.org/show_bug.cgi?id=344129) But there is a libddraw.lib in the official mingw-win32-api package (Yes it's weird). Withtout this patch those plugins cannot be build with the current Makefile.am files in current git. So I am ok with this patch. For a later improvement, about directdrawsink/Mafile.am, as it exists always libddraw.a, maybe it can be used with the ddraw.h file in DXSDK_DIR (this var is set when installing the microsoft directx SDK). I am not sure if this libddraw.a is compatible with the ddraw.h header in DXSDK_DIR, can you check that ? About directsoundsrc and directsoundsink the following bug has to be considered: http://bugzilla.gnome.org/show_bug.cgi?id=584980
"But there is a libddraw.lib" -> you should read "But there is a libddraw.a"
commit 936d87f64b2d6cc66d689910dd5a8cbd3d63b055 Author: Руслан Ижбулатов <lrn1986@gmail.com> Date: Wed Aug 26 01:18:00 2009 +0100 directdraw, directsound: unify CFLAGS and fix configure checks for DirectX-based plugins One set of CFLAGS for all DirectX-based plugins. Correct header/library checks for DirectX-based-plugins. Remove unused variable and label in directsoundsrc. Fixes #593068.
(In reply to comment #1) > According to your patch, I think this is directsoundsrc.c and not > directdrawsink.c > ? Yep, mistyped. > > And yes there is no "dsound.h" and "ddraw.h" in the official mingw-win32-api > package (see comment #22) http://bugzilla.gnome.org/show_bug.cgi?id=344129) Yep, that is why DX SDK is used. > But there is a libddraw.a in the official mingw-win32-api package (Yes it's > weird). Yep, because headers are all the same, but an .a library is needed to link with MinGWis programs. So they do supply .a library, but not headers. > > For a later improvement, about directdrawsink/Mafile.am, as it exists always > libddraw.a, maybe it can be used with the ddraw.h file in DXSDK_DIR (this var > is set when installing the microsoft directx SDK). I am not sure if this > libddraw.a is compatible with the ddraw.h header in DXSDK_DIR, > can you check that ? I'm using dsound.h and ddraw.h from DX SDK exclusively. /mingw/lib/libddraw.a is compatible with ddraw.h H-m-m, didn't know about DXSDK_DIR variable. Although in my case it points to an old DX SDK from August 2007, while i'm using the one from November 2008, so it's not that useful. And i have to obtain a shortname anyway (GCC is supposed to accept long names in double quotes, but when MSys and CFLAGS are thrown into a mix something just doesn't work there). > About directsoundsrc and directsoundsink the following bug has to be > considered: > http://bugzilla.gnome.org/show_bug.cgi?id=584980 My goal is to make things buildable at a given moment. If some of my changes are not compatible with upcoming improvements, they can be revised/reversed.
> Yep, because headers are all the same, but an .a library is needed to link with > MinGWis programs. So they do supply .a library, but not headers. Oh ok you are using LMS DX SDK. (I thought you was using a mingw direct x package, which is not official and as you explain it's now obsolete) Ok I saw there is also libdsound.a etc... I was not sure those headers was compatible with mingw. Good :P