September 2011 - Wine-Devel

Re: setupapi: Fix a few pointer cast warnings.

by Alexandre Julliard

Jerome Leclanche <adys.wh(a)gmail.com> writes: > From c8a7535beebb152641330d3d1410d17345522867 Mon Sep 17 00:00:00 2001 > From: Jerome Leclanche <adys(a)azura> > Date: Thu, 1 Sep 2011 12:51:26 +0100 > Subject: [PATCH] setupapi: Fix a few pointer cast warnings. That's just hiding the pointer truncation bug. -- Alexandre Julliard julliard(a)winehq.org

Sept. 1, 2011

Re: kernel32: Fix writing to a pipe in WriteConsoleW().

by Francois Gouget

On Wed, 24 Aug 2011, Eric Pouech wrote: [...] > you can safely provide the patches with protecting WriteConsole and friends > with a if (!is_console_handle(???)) return FALSE; line Would something like the attached patch be ok? As far as I can see all the other APIs pretty much immediately pass the handle to wineserver which I expect will complain if it's not a console handle. Further notes: * Performing the 'console handle check' locally would likely be faster but, except for WriteConsole maybe, this should usually be the case and is probably not performance critical anyway. * There are a few cases where we check for invalid parameters and return an error before the handle is checked by wineserver. It's possible that in such cases Windows checks the handle first. But unless we know of applications that need the right error code in these corner cases it does not justify adding an explicit check. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Sept. 1, 2011

Re: buildbot status

by Dan Kegel

On Thu, Sep 1, 2011 at 4:04 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > Note that virtual desktop breaks some (iirc user32) tests, unless > that's something that was fixed recently. I work around it. There were only a couple. - Dan

Sept. 1, 2011

re: po: Fix some typography issues in the Czech translation.

by Dan Kegel

This patch found a bug in my scripts - it failed to grep the patch for sender and subject - but it looks like there might be something wrong with the patch itself, it doesn't apply here. Buildbot said: Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/194 BUILD FAILED: failed git and here's what I get when I do it by hand: $ wget http://source.winehq.org/patches/data/78249 $ git apply 78249 typocz.patch:31: trailing whitespace. msgstr "Ověřte prosím, že název souboru byl zadán správně" typocz.patch:40: trailing whitespace. "Chcete ho vytvořit?" typocz.patch:49: trailing whitespace. "Chcete ho přepsat novým?" typocz.patch:54: trailing whitespace. msgstr "Nedovolený(é) znak(y) v cestě k souboru" typocz.patch:63: trailing whitespace. "Chcete ho přepsat novým?" error: patch failed: po/cs.po:210 error: po/cs.po: patch does not apply

Sept. 1, 2011

Re: 78217: Subject: [PATCH 3/3] winecfg: Remove driver selection from Audio tab

by Andrew Eikum

On Wed, Aug 31, 2011 at 01:25:41PM -0700, Dan Kegel wrote: > Ah, I see you resent a fixed version, sorry for the noise. Thanks just the same. Because of your bot's email, I was able to know to resend the patch before I ran out the door. Andrew > (FWIW, the bot won't test your retry, since it was an incomplete patch series.) > > On Wed, Aug 31, 2011 at 1:22 PM, Dan Kegel <dank(a)kegel.com> wrote: > > On Wed, Aug 31, 2011 at 1:10 PM, <buildbot(a)buildbot.kegel.com> wrote: > >> The Buildbot has detected a failed build on builder runtests while building Wine. > >> Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/161 > >> BUILD FAILED: failed git > > > > Something's fishy; looking at > > http://marc.info/?l=wine-patches&m=131134541100364&w=2 > > I see that the July 22nd version seems to have interesting strings, > > but the August 31st version has all question marks when it comes to > > non-ascii text. > > What happened between the two? > > > > http://source.winehq.org/patches/data/78217, which is where I pulled > > the patch from, > > also has the question marks. > >

Sept. 1, 2011

Re: services: Issue a fixme when a service fails to start.

by Octavian Voicu

On Thu, Sep 1, 2011 at 4:02 PM, Francois Gouget <fgouget(a)codeweavers.com> wrote: > @@ -295,7 +295,8 @@ static void scmdatabase_autostart_services(struct scmdatabase *db) > argv[0] = service->name; > argv[1] = NULL; > err = service_start(service, 1, argv); > - /* FIXME: do something if the service failed to start */ > + if (err != ERROR_SUCCESS) > + WINE_FIXME("do something if the service failed to start %d\n", err); Why not print something more informative? This looks nice and also tells you which service did not start: WINE_FIXME("Auto-start service %s failed to start: %d\n", wine_dbgstr_w(service->name), err); Octavian

Sept. 1, 2011

Re: file

by buildbot＠kegel.com

The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/194 BUILD FAILED: failed git For more info about this message, see http://wiki.winehq.org/BuildBot

Sept. 1, 2011

Re: Daily builds of latest Git now available as Ubuntu packages

by Scott Ritchie

On 09/01/2011 05:05 AM, Alex Bradbury wrote: > On 1 September 2011 10:50, Scott Ritchie <scott(a)open-vote.org> wrote: >> For an easier user testing experience, you can now install the latest >> git as a convenient Ubuntu package. > > This seems very handy, thank you. > > As this seems like as good a place as any for Ubuntu packaging of wine > - do you see any fix in the future for gstreamer support on Wine when > compiling on 64-bit Ubuntu? The current Wine configure script (quite > correctly) disables support because the installed glibconfig.h > includes type definitions correct for 64-bit compilation for incorrect > for 32-bit compilation. ia32-libs doesn't contain header files and > there is no other package that can provide the 32-bit header. Perhaps > proper multilib support in the upcoming 11.10 provides a solution? > > Alex I'll work on this for Oneiric beta, after I'm done with that it's possible I can backport it to Natty but no guarantees. Thanks, Scott Ritchie

Sept. 1, 2011

Re: Daily builds of latest Git now available as Ubuntu packages

by Scott Ritchie

On 09/01/2011 05:21 AM, Henri Verbeet wrote: > On 1 September 2011 11:50, Scott Ritchie <scott(a)open-vote.org> wrote: >> The packages are versioned like wine1.3-1.3.27+daily-20110901. >> >> Limitations: >> The major version number is based on the latest released version of the >> Ubuntu packages, so on release days you might see something like >> 1.3.27+daily-20110909 which would actually be equivalent 1.3.28. If I >> get especially behind and don't update the official packages after >> Monday, you might even see a "1.3.27+daily" that's actually ahead of 1.3.28. >> > I don't use Ubuntu, so this doesn't really affect me, but can't you > use the output from "git describe" for the version? Unfortunately I have to use Launchpad Recipe's supported substitution variables here, and while they do have one for the latest git-tag if I build locally this doesn't work on launchpad itself. The reason for this is that the launchpad recipe builders don't have git proper, but instead rely on bzr-git imports (the package is actually building off the launchpad bzr import of the Wine git tree merged with my packaging bzr branch). Yeah it's a bit lame, and I'll raise the issue with the launchpad folks when I see them next, but it's a pretty minor problem atm. Thanks, Scott Ritchie

Sept. 1, 2011

Re: Daily builds of latest Git now available as Ubuntu packages

by Octavian Voicu

On Thu, Sep 1, 2011 at 3:05 PM, Alex Bradbury <asb(a)asbradbury.org> wrote: > As this seems like as good a place as any for Ubuntu packaging of wine > - do you see any fix in the future for gstreamer support on Wine when > compiling on 64-bit Ubuntu? The current Wine configure script (quite > correctly) disables support because the installed glibconfig.h > includes type definitions correct for 64-bit compilation for incorrect > for 32-bit compilation. ia32-libs doesn't contain header files and > there is no other package that can provide the 32-bit header. Perhaps > proper multilib support in the upcoming 11.10 provides a solution? One way to do this is setup an i386 chroot (using debootstrap + schroot) and use that to build 32-bit wine. I used this setup to test the gstreamer patch and it works without a glitch. See [1] for more info. Multiarch support already kind of works in current Ubuntu (11.04), though not that excellent and it's not yet enabled by default. Haven't tried installing glib-dev using that, but I'm guessing that even if it did work pkgconfig most likely won't know about it, so we would have the wrong -I flags output from the configure script (because there is no way for us to specifically ask pkgconfig for a certain architecture). Anyway, what do you use gstreamer for or what applications use it? I'm the one that "broke it", but to be honest I based my assessment that it was already broken just by reading the code, not by actually testing it with an application. Octavian [1] https://help.ubuntu.com/community/DebootstrapChroot

Sept. 1, 2011

Re: Daily builds of latest Git now available as Ubuntu packages

by Henri Verbeet

On 1 September 2011 11:50, Scott Ritchie <scott(a)open-vote.org> wrote: > The packages are versioned like wine1.3-1.3.27+daily-20110901. > > Limitations: > The major version number is based on the latest released version of the > Ubuntu packages, so on release days you might see something like > 1.3.27+daily-20110909 which would actually be equivalent 1.3.28. If I > get especially behind and don't update the official packages after > Monday, you might even see a "1.3.27+daily" that's actually ahead of 1.3.28. > I don't use Ubuntu, so this doesn't really affect me, but can't you use the output from "git describe" for the version?

Sept. 1, 2011

Re: Daily builds of latest Git now available as Ubuntu packages

by Alex Bradbury

On 1 September 2011 10:50, Scott Ritchie <scott(a)open-vote.org> wrote: > For an easier user testing experience, you can now install the latest > git as a convenient Ubuntu package. This seems very handy, thank you. As this seems like as good a place as any for Ubuntu packaging of wine - do you see any fix in the future for gstreamer support on Wine when compiling on 64-bit Ubuntu? The current Wine configure script (quite correctly) disables support because the installed glibconfig.h includes type definitions correct for 64-bit compilation for incorrect for 32-bit compilation. ia32-libs doesn't contain header files and there is no other package that can provide the 32-bit header. Perhaps proper multilib support in the upcoming 11.10 provides a solution? Alex

Sept. 1, 2011

Re: [1/5] ddraw: Simplify Z format parsing a bit, remove ERRs

by Henri Verbeet

On 1 September 2011 11:01, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > case 32: > if(DDPixelFormat->u2.dwStencilBitDepth == 8) > return WINED3DFMT_D24_UNORM_S8_UINT; > - else > + else if (DDPixelFormat->u2.dwStencilBitDepth == 4) > return WINED3DFMT_S4X4_UINT_D24_UNORM; I'm not sure if this is intentional or not, but you fallthrough to the default case here. If that's intentional, a /* Fallthrough */ or similar comment wouldn't hurt. On the other hand, you do explicitly handle it in the no-stencil case.

Sept. 1, 2011

Re: buildbot status

by Henri Verbeet

On 1 September 2011 09:19, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > The iMac would be an idea, but there's still a rather nasty issue with the lack of xrandr and xvidmode support on Apple's X server, and a wine hack that is needed with CrossOver's X server. If I read your scripts correctly you run the tests in a virtual desktop, in which case this wouldn't be an issue. > Note that virtual desktop breaks some (iirc user32) tests, unless that's something that was fixed recently. > If on the other hand you have an system with a AMD GPU(using fglrx or the open source driver doesn't matter) > Did the tests start passing on fglrx then?

Sept. 1, 2011

Re: [PATCH 1/5] ddraw: Make the OpenGL renderer the default one.

by Henri Verbeet

On 1 September 2011 09:27, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am 31.08.2011 um 12:29 schrieb Henri Verbeet: >> Well, DirectDraw 2D-only applications, but yes. All three people in >> that situation should either install a software GL renderer or >> explicitly set the "DirectDrawRenderer" registry key to "gdi". > My mail is a bit late, but the programs I'm mainly concerned about are Internet Explorer and Windows Media Player. If someone wants to play a game in a VNC X server that's a crazy enough setup that setting an extra registry key doesn't matter, but running IE in VNC isn't that unusual. > So you install a software GL renderer, use something that actually works with indirect GL, or set "DirectDrawRenderer" to "gdi". Plenty of reasonable options to make it work I'd say. If you really want to go out of your way to make this work you can even make the fallback to gdi automatic, but it would have to be before any surfaces or swapchains are created, I'm not putting the surface type switching code back in. Preferably this would work by making the surface type just go away on the wined3d side, and just not exposing any GL based blitters or 3D rendering. >>> It will make it impossible to run some apps out of the box(e.g. the ones >>> currently affected by bug 2082, and old QuickTime versions). That's fine with >> I'm not sure how this will make it more impossible to fix that bug. > Well, without opengl we can still render to the NULL hwnd, even if it has issues like not working with a compositing Window manager(Windows disables aero when a ddraw app doesn't specify a clipping window). OpenGL refuses to do that. So you don't use GL to render to that. For simple blits, it should be fairly trivial to only use CPU blits when blitting to the root window. For actual 3D rendering you'd have to create an intermediate offscreen target to render to, which is probably somewhat harder. But then, with the GDI renderer this doesn't work at all.

Sept. 1, 2011

Re: configure.ac: add -Werror to default compiler options

by Per Johansson

(resent with correct from-address, please ignore the previous one) 1 sep 2011 kl. 03:27 skrev Dan Kegel: > At which point it would probably be a fine idea to add -Werror by default; > buildbot will help keep everyone in sync, even if they're using a compiler > that doesn't catch as many warnings as the one buildbot uses. We use -Werror at my company, but I think you should really think twice before enabling it for a distributed package. New compiler versions add new warnings. Usually correctly so, but there's no way to know what warnings will be produced by what compiler, and keeping up with new compilers requires a bit of effort. We make sure to always test new compilers separately before upgrading on the developing machines. I think most users will probably just see that the package fails to build, and assume it's broken. Ps. I know there's also a few warnings while building on OS X. I don't have access to it now, or I'd send the list. -- Per Johansson

Sept. 1, 2011

Re: configure.ac: add -Werror to default compiler options

by Michael Stefaniuc

Dan Kegel wrote: > (Reviving http://www.winehq.org/pipermail/wine-devel/2008-September/069266.html > ) > > After > http://www.winehq.org/pipermail/wine-patches/2011-August/106150.html and > http://www.winehq.org/pipermail/wine-patches/2011-August/106151.html, > configuring with -Wall -Werror gives the right results, > judging by a quick diff of config.h and config.status. > > (sys/asoundlib.h is not detected, but that's ok, it's marked as obsolete, > and wine uses alsa/asoundlib.h instead.) > > This takes care of Maarten's concerns from the earlier thread. > > Then building yields only a tiny handful of errors: > > dllfunc.c: In function ‘AMovieDllRegisterServer2’: > dllfunc.c:180: warning: dereferencing type-punned pointer will break > strict-aliasing rules > qualitycontrol.c: In function ‘QualityControlImpl_Notify’: > qualitycontrol.c:70: warning: dereferencing type-punned pointer will > break strict-aliasing rules > transform.c: In function ‘TransformFilterImpl_QueryInterface’: > transform.c:248: warning: dereferencing type-punned pointer will break > strict-aliasing rules > ../../include/winternl.h: In function ‘get_vm86_teb_info’: > ../../include/winternl.h:2660: warning: dereferencing type-punned > pointer will break strict-aliasing rules > ... > register.c: In function ‘create_registrar’: > register.c:66: warning: dereferencing type-punned pointer will break > strict-aliasing rules > > Those are potential, if unlikely, bugs; we ought to either fix them or > add -fno-strict-aliasing > to CFLAGS for the seven or so affected .c files. > > At which point it would probably be a fine idea to add -Werror by default; > buildbot will help keep everyone in sync, even if they're using a compiler > that doesn't catch as many warnings as the one buildbot uses. You can try submitting a patch to add -Werror by default but I already know the patch status that it will get: REJECTED!!11!! You might get away with enabling it for the buildbot as you can enforce a controlled environment. But enabling it in general is such a bad idea that it isn't funny. No clue why people insist to still do it. Ask packagers what they think about upstreams that do that, disabling that is one of the first actions they do. bye michael

Sept. 1, 2011

Daily builds of latest Git now available as Ubuntu packages

by Scott Ritchie

For an easier user testing experience, you can now install the latest git as a convenient Ubuntu package. The instructions are very similar to using the standard Ubuntu packages, however the PPA name is different. Instead of ppa:ubuntu-wine/ppa, you add ppa:ubuntu-wine/daily. >From a terminal: sudo add-apt-repository ppa:ubuntu-wine/daily sudo apt-get update sudo apt-get install wine1.3 The packages are versioned like wine1.3-1.3.27+daily-20110901. Limitations: The major version number is based on the latest released version of the Ubuntu packages, so on release days you might see something like 1.3.27+daily-20110909 which would actually be equivalent 1.3.28. If I get especially behind and don't update the official packages after Monday, you might even see a "1.3.27+daily" that's actually ahead of 1.3.28. In all cases wine --version should return what it normally does, however - this is just the package revision that is being wonky. Possible future: These packages are a convenient way to run some tests that may be much too slow for testbot to run against every patch, such as autohotkey-based application automation. Thanks, Scott Ritchie

Sept. 1, 2011

winecoreaudio: Fix AudioRenderClient Get/ReleaseBuffer protocol.

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, I've one idea left about what may have caused the 2 apply failures. The patches are in my git queue just above wine-1.3.27 and the unrelated Valgrind hacks, so in theory, they should work. However the patches depend on each other, but since I reused the subject line of patches originally submitted with several days spacing between them, I forgot to add [PATCH 1/N] this week. The order is: 0001-winecoreaudio: Fix AudioRenderClient Get/ReleaseBuffer protocol. 0002-mmdevapi: Do not mix frames and bytes. (in git now, but should not interfere) 0003-mmdevapi: Use UINT32 for a number of frames and UINT64 to sum them. Perhaps you tried out UINT32 first? Please try Get/Release first. My apology for the trouble, Jörg Höhle

Sept. 1, 2011

Re: configure.ac: add -Werror to default compiler options

by Jerome Leclanche

Here is a warning report from a 64bit system. I get a lot of warnings on both 32 and 64bit wines. Many of them are "variable set but not used" (unused error returns, ...). http://bugs.winehq.org/show_bug.cgi?id=26768 was filed a while ago for the oleaut32 spam. On Thu, Sep 1, 2011 at 7:13 AM, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > On Thu, Sep 1, 2011 at 4:27 AM, Dan Kegel <dank(a)kegel.com> wrote: >> At which point it would probably be a fine idea to add -Werror by default; >> buildbot will help keep everyone in sync, even if they're using a compiler >> that doesn't catch as many warnings as the one buildbot uses. > > Have you tried compiling on 64-bit? There are still a handful of > compile warnings there (most in oleaut32/tmarshal.c; then > setupapi/devinst.c; dsound+winmm). > > Octavian > > >

Sept. 1, 2011

Re: configure.ac: add -Werror to default compiler options

by Per Johansson

1 sep 2011 kl. 03:27 skrev Dan Kegel: > At which point it would probably be a fine idea to add -Werror by default; > buildbot will help keep everyone in sync, even if they're using a compiler > that doesn't catch as many warnings as the one buildbot uses. We use -Werror at my company, but I think you should really think twice before enabling it for a distributed package. New compiler versions add new warnings. Usually correctly so, but there's no way to know what warnings will be produced by what compiler, and keeping up with new compilers requires a bit of effort. We make sure to always test new compilers separately before upgrading on the developing machines. I think most users will probably just see that the package fails to build, and assume it's broken. Ps. I know there's also a few warnings while building on OS X. I don't have access to it now, or I'd send the list. -- Pelle Johansson

Sept. 1, 2011

Re: [3/7] dinput: Added enumerated devices to ConfigureDevices dialog

by Marcus Meissner

On Tue, Aug 30, 2011 at 09:11:33PM -0300, Lucas Zawacki wrote: > > It doesn't make sense to pass the info as WM_INITDIALG parameter if it's > > going to be stored in global variables anyway. A better way would be to > > store this in the window info. > > > > Any pointers on what's the set of winapi functions used to store and > retrieve data in windows? I've searched MSDN for almost 30 minutes and > no luck. SetPropA/W Also offset 0 of the window longs are usually used, like e.g. in comctl32/tooltips.c: SetWindowLongPtrW (hwnd, 0, (LONG_PTR)infoPtr); Ciao, Marcus

Sept. 1, 2011

Re: [PATCH 1/5] ddraw: Make the OpenGL renderer the default one.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.08.2011 um 12:29 schrieb Henri Verbeet: > On 31 August 2011 10:58, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> This will break 2D-only apps in situations where OpenGL is not available. It > Well, DirectDraw 2D-only applications, but yes. All three people in > that situation should either install a software GL renderer or > explicitly set the "DirectDrawRenderer" registry key to "gdi". My mail is a bit late, but the programs I'm mainly concerned about are Internet Explorer and Windows Media Player. If someone wants to play a game in a VNC X server that's a crazy enough setup that setting an extra registry key doesn't matter, but running IE in VNC isn't that unusual. >> It will make it impossible to run some apps out of the box(e.g. the ones >> currently affected by bug 2082, and old QuickTime versions). That's fine with > I'm not sure how this will make it more impossible to fix that bug. Well, without opengl we can still render to the NULL hwnd, even if it has issues like not working with a compositing Window manager(Windows disables aero when a ddraw app doesn't specify a clipping window). OpenGL refuses to do that. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJOXzPPAAoJEN0/YqbEcdMwp0wP/31DLijd+24l30IT0Apk0Gru FyOzYdGynHuZ0AyO0tNa7EH+bAxrrBqNxJw2yuBrcgB5iLoqwE8xehuEVpQ26oA4 JCbd820uPtf8ijnIeTD2wc6UEq8noZfyM+DUo8419w08RrLD5LdB3feHUeWTXZZA iT1UiRmIornAU9HgHpCMBlwmDvSG3EGhtgcRPwo4ABgnvkvn7yiAIH0s8ZUkUgVH I0WtL2Wx7pFWhqbRblsrqTrdUZI0nzkvDuZHoFyU9mVKSX+AMLO/r/1TeC6HynaJ RS11ngFRgogLQFLhxUSocfQk5lccqeb+jw9HtHvKPjWMKHwZLSOJArvGTeMQoujG DDim4tst/7dPKVlU9m29rNijX2iVpGCcwFeeR94XXFj6L9Am6HkapxOJTap+Knl0 gVzYJSRnAITVIa2E9UMicMjU3SifC2+sSgY/J9FGs4yOLqCV0cwRrGmUzcbwYhAu crLPDcnbIzy0H05kKbRTDzA329jH0T4dAFveoyRAIEHTYpI9tWoLVP8yKgJ5edlG wTA+HkU3IhVyQmOVlIWL4pJ6qe5oVQ2aT58WCpxGcWQoZBsJh6mltq6i/zTJcjk8 ZA5hR6SjJOSiY+xVXdjE/zSBUp49rZhhBUzr0CQGQdEiFQvlKIwDiY8TwRrcY3HO encWQArhsqvqeyGyIWzz =YifS -----END PGP SIGNATURE-----

Sept. 1, 2011

Re: buildbot status

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 01.09.2011 um 01:12 schrieb Dan Kegel: > it'd probably be a better use of time to bring up a modern ati system? If I had one I could use as-is, yes. My computer with a modern AMD GPU is in my working and sleeping room, where I'd like to keep it for coding, but I can't keep it on all the time. The iMac would be an idea, but there's still a rather nasty issue with the lack of xrandr and xvidmode support on Apple's X server, and a wine hack that is needed with CrossOver's X server. If I read your scripts correctly you run the tests in a virtual desktop, in which case this wouldn't be an issue. If on the other hand you have an system with a AMD GPU(using fglrx or the open source driver doesn't matter) and have some issues setting it up(e.g. the d3d tests crashing the X server) I can look into those issues and help you get it running on your side. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJOXzIBAAoJEN0/YqbEcdMwmC4P/AwxunC+lpXf84G6VnRkoIUA SuoZV79t10WFpfI4JJLlmJdB3BPsbQIQoXb22iWc6wQqOtUC9luKIyzZCLEOxQ1l +C+lA8IYvlFDb5A0Cjf92B0LBIWDOHc4EzrizANVIrdiWPzY0kW+/OhqcNWbC59f IxbiARtoum7gFSwXJToe2OWG9DRuBwhPlaoXkPq4sbLFR//SnoYab8agmbP6sd5n 5Umi0RdAeSVIXVNUv2QZsBIrMWdcg9k4Dg3epauExKyE7P+G26awSmpVfqgCNQMU DrekgeICoGTTPYIgDJAsTQ6hyyD2vsoXuQNcoWRoAJv06+pwMvXvzknX2X2batiP nEkZoQj13QMJKyT6cby3GKKC4xdRhUzfmilAbLWoGwX8QWq7c2oLqTUgo1pJ2Iku Stgqef2J6Sj+9y/6xAMtwOuDNWx7bb0m0R/ReLWs5uu+4oB683hiGLVofvC+d5tw TgOa3zpo74a/rZIopY/6kA5rITmiwC2kYx3WKxaGrI/jfUfvaLFmbU45ShwJvQDu lkDb6Rs6hz4pyBXBkeC8DHkL+phogEB5ZGZQryoA1bWUdB7mvS9SnfiT8vgyMx/g 7KPlHJ3rlfC8sRkwdCGDt8gv1BhM6TPoKqN04vKACYeaB0uFJOmo3p+kJ2F+lXUn zCy6QZ0cpFKwFlkXm2HK =a472 -----END PGP SIGNATURE-----

Sept. 1, 2011

Re: configure.ac: add -Werror to default compiler options

by Octavian Voicu

On Thu, Sep 1, 2011 at 4:27 AM, Dan Kegel <dank(a)kegel.com> wrote: > At which point it would probably be a fine idea to add -Werror by default; > buildbot will help keep everyone in sync, even if they're using a compiler > that doesn't catch as many warnings as the one buildbot uses. Have you tried compiling on 64-bit? There are still a handful of compile warnings there (most in oleaut32/tmarshal.c; then setupapi/devinst.c; dsound+winmm). Octavian

Sept. 1, 2011