November 2007 - Wine-Devel - list.winehq.org

Re: [14/15] WineD3D: Get rid of the conditionals in shader_glsl_compare

by Mirek Slugeň

Nov. 9, 2007

Re: [6/15] WineD3D: Replace the position fixup mul-add-add with a MAD

by Stefan Dösinger

Am Freitag, 9. November 2007 16:50:54 schrieb Mirek Slugeň: > Hi, this patch caused regression in Nvidia SDK demo BloodShader.exe and > some other games, the main problem is in geometry of some objects, so it > colud be related to vertex shaders. Can you describe the issues a bit more detailed? (e.g. screenshots?)

Nov. 9, 2007

Re: [6/15] WineD3D: Replace the position fixup mul-add-add with a MAD

by Mirek Slugeň

Nov. 9, 2007

Re:

by Stefan Dösinger

Am Freitag, 9. November 2007 16:34:30 schrieb Francois Gouget: > On Fri, 9 Nov 2007, Juan Lang wrote: > [...] > > > I'm afraid I can't provide very direct assistance, but your configure > > log indicates something pretty basic is screwed up: > > > > configure:2404: checking for C compiler default output file name > > configure:2431: gcc conftest.c >&5 > > /usr/bin/ld: can't locate file for: -lcrt1.o > > collect2: ld returned 1 exit status > > You're probably missing the libc6-dev and/or libgcc1 packages (the > package names may be slightly different on your distribution). uname -s = Darwin uname -v = Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 It is a mac it seems. Is Xcode installed?

Nov. 9, 2007

Re:

by Francois Gouget

On Fri, 9 Nov 2007, Juan Lang wrote: [...] > I'm afraid I can't provide very direct assistance, but your configure > log indicates something pretty basic is screwed up: > > configure:2404: checking for C compiler default output file name > configure:2431: gcc conftest.c >&5 > /usr/bin/ld: can't locate file for: -lcrt1.o > collect2: ld returned 1 exit status You're probably missing the libc6-dev and/or libgcc1 packages (the package names may be slightly different on your distribution). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.

Nov. 9, 2007

Re: Valgrind results for Oct 8: lots of hangs?!

by Stefan Dösinger

Am Freitag, 9. November 2007 03:26:52 schrieb Dan Kegel: > Data online at > http://kegel.com/wine/valgrind/20071108/ > > For some reason, today I had to do 'wineserver -k' > about five times (yesterday and the day before > only once). And one of those times was during > a d3d9 test which took over / hung the screen; not > even ctl-alt-backspace helped, I actually had to reboot > (I didn't try ssh'ing in). Running the tests was like > pulling teeth. > > That said, here are the changes in the list of bad tests; > - means test didn't show any valgrind errors today but did yesterday, > + means it did show valgrind errors today but not yesterday. Do you have time to do a regression test for the patch that broke the d3d9 test? The most suspicious patch is b4b10d8bc2d6c7a9191898d3a03420bdcae9c6f2 . Finding the patch might give some hints to the X server crashes on Mesa drivers. The d3d9:visual failures are gone, but I think this is because the test didn't run to completion. This patch fixes a memleak, but a few other memleaks are still left.

Nov. 9, 2007

Re:

by Juan Lang

Hi Colin, > In particular, I am unfamiliar with the 'configure' executable > described in your installation manual. This script is produced by autoconf. It's the way many (most?) packages are built these days. I'm afraid I can't provide very direct assistance, but your configure log indicates something pretty basic is screwed up: configure:2404: checking for C compiler default output file name configure:2431: gcc conftest.c >&5 /usr/bin/ld: can't locate file for: -lcrt1.o collect2: ld returned 1 exit status It reports the failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "0.9.37" | #define PACKAGE_STRING "Wine 0.9.37" | #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } This is as basic a program as it gets. So, try creating a similarly empty .c file by hand, and compiling it yourself. If you get a similar error, figure out what's wrong with your compiler installation, and fix that. If you don't, I don't know what to tell you. Good luck, --Juan

Nov. 9, 2007

Re: xrun handling in winealsa.drv

by Timofei V. Bondarenko

Maarten Lankhorst wrote: > Hello Timofei, > > Timofei V. Bondarenko schreef: >> I've noticed the winealsa does not handle alsa XRUNs. >> In the case of XRUN application hangs. >> > I'm aware of the xrun problems in alsa at least the accelerated parts > (dsoutput/dscapture), it's been on my todo list for a while but I've > been busy lately. The problems with the accelerated parts are not the > underruns themselves. They are handled correctly in the places where it > matters. The problem is how the underruns are handled in the directsound > software mixer. I haven't taken a look yet at how underruns are handled > for the not-accelerated system, but I believe that the chance of a > underrun there is already very low because buffers there usually have a > latency of at least 300ms. No matter how low the chance: sound is an real-time task while linux is not a real-time system. So underruns still possible. And in case of XRUN widRecorder() tries to read about 4G of data. Well, I'm a busy man too. So I've wrote a simple patch and sent it to wine-patches. Please look. May be it will be more clear in C than in my broken english. Regards, Tim.

Nov. 9, 2007

Re: #winehq admin troubles

by Ben Hodgetts (Enverex)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There's something many people are missing here and something that the "noobs" enforce. They come in, know little about wine, then attempt to "help" other people, of course they don't because their information and suggestions are wrong and either a) do nothing, b) make more work for other people or c) make it considerably worse. It's an annoying trend and becomes infuriating for anyone (especially when they start insulting you as well). I'm pretty sure Ghandi would have KO'ed someone with his keyboard by now. So remember kids, bad advice is worse than no advice. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHNFZIuqCUopk11kIRAlK9AJ9K40UwG1cRniG/8pyYPwl7HaZSPACfdpJ4 +J934XIwR4ftWqjqMrE9cqM= =e+yU -----END PGP SIGNATURE-----

Nov. 9, 2007

Re: wininet: check the return value from HeapAlloc in a test

by Alexandre Julliard

"Lei Zhang" <thestig(a)google.com> writes: > We should skip a test if HeapAlloc() fails. There's no need to clutter up the tests with allocations checks, if we are out of memory pretty much everything in the test is going to fail anyway. -- Alexandre Julliard julliard(a)winehq.org

Nov. 9, 2007