Re: Yesterday's (6/28) Git (gdi32) updates break 64-bit compilation.
"Evil Jay" <[EMAIL PROTECTED]> wrote: ld: Relocatable linking with relocations from format elf64-x86-64 (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.n0hnjc.o) is not supported winebuild: ld -m elf_i386 -r failed with status 256 That's quite strange since apparently nothing has changed in the bidi support in GDI. Do you have HAVE_ICU or HAVE_UNICODE_UBIDI_H defined in your config.h? What happens if you #undef'ine them? Also try to exec 'make clean' as a general rule. -- Dmitry.
Re: [D3D9] Remove const qualifier on state_test data.
Michael Stefaniuc wrote: Ivan Gyurdiev wrote: Type: Cleanup Why: The const qualifier is unnecessarily restrictive. I intend to allocate and free such data on the heap in a future patch. Instead, const should be primarily used on function parameters. Question: do you realy have to use void pointers? Yes. Void pointers are compatible with every pointer type and thus will disable the type checking of the compiler. This is intentional - it's a form of polymorphism. The data stored can be of many different types. Each test knows what type of data it is using. Also you do not need to to cast a rvalue to void * if the type of the lvalue is void *. Yes, you do...the type of the lvalue is void*, while the type of the rvalue is const void*. Not casting produces a warning (correctly). Casting replaces the compile-time guarantee that the value will be kept constant by runtime contract [ because both const and non-const rvalue will be used in the future ].
Re: [Bug 4995] Check for fontforge >= 20060406 as earlier versions fail to build our fonts with catastrophic results.
On 9/29/06, Vitaliy Margolen <[EMAIL PROTECTED]> wrote: Also your patch is not correct. It's been discussed on wine-devel that we should not restrict any one particular version of FontForge. Many distros come with old but good versions and this will add extra noise for no good reason. And it will not catch any new versions that are broken either... Vitaliy. Could someone tell me which version works the best? It seems to be a mystery. I've been using a snapshot of fontforge from 2006-08-22. Jesse
Vista applications that work & those that don't
I thought this may be of interest... applications that work and those that don't in Vista RC1 It would be interesting on how this same list compares with wine 0.9.22 http://www.iexbeta.com/wiki/index.php/Windows_Vista_Software_Compatibility_List and the hardware compatibility list .. http://www.iexbeta.com/wiki/index.php/Windows_Vista_RC_1_Hardware_Compatibility_List I don't believe Microsoft's official list has been made public yet, although they said they would sometime! Nick
Re: [Bug 4995] Check for fontforge >= 20060406 as earlier versions fail to build our fonts with catastrophic results.
Sam Dennis wrote: > aclocal.m4 | 16 > configure.ac |6 +- > 2 files changed, 21 insertions(+), 1 deletions(-) > You missing change log. Please don't forget to include it in the email body not just subject. Also your patch is not correct. It's been discussed on wine-devel that we should not restrict any one particular version of FontForge. Many distros come with old but good versions and this will add extra noise for no good reason. And it will not catch any new versions that are broken either... Vitaliy.
Re: shdocvw(2/2): ignore VT_ERROR arguments to WebBrowser_Navigate2
Juan Lang wrote: >>Ignoring VT_ERROR just masks a previous error. > > > Hm.. are you sure? These are input arguments, not results. This isn't You can never be sure with this OLE stuff. My only experience with VT_ERROR stems from variant arithmetics and those functions didn't like VT_ERROR as input. Well except VarCmp when both input variants where VT_ERROR it would return "equal". > the only app that gets further with this patch. See also bug 6166. > > I guess a test case is the only answer. Definitely. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: shdocvw(2/2): ignore VT_ERROR arguments to WebBrowser_Navigate2
Hi, Juan Lang wrote: >> Ignoring VT_ERROR just masks a previous error. >> > > Hm.. are you sure? These are input arguments, not results. This isn't > the only app that gets further with this patch. See also bug 6166. > > I guess a test case is the only answer. > I've tested it and we really shouldn't return E_INVALIDARG in this case so your patch is good. Thanks, Jacek
Re: [PATCH 0/4] Janitorial: Win64 printf format warning fixes
Michael Stefaniuc wrote: > For all the people wanting to help out with this janitorial task please > wait until Alexandre commits this patch series. After that i'll create a > page for this task on the Wine wiki and link it from > http://wiki.winehq.org/JanitorialProjects Ok, this janitorial task has now a Wiki page: http://wiki.winehq.org/Win64PrintfFormatWarnings This is a good opportunity for anybody that wants to start submitting patches for Wine and get accustomed to this process. > I will put in a download link for my perl script that can automaticly > fix around 2 out of the remaining 25000 warnings. You realy do not > want to go manualy over 25k warnings. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: Can't open DLL's without sudo
On 9/29/06, James Hawkins <[EMAIL PROTECTED]> wrote: On 9/28/06, Paul Wilkinson <[EMAIL PROTECTED]> wrote:> What's the point of giving new people attitude? Of course I read the error> messages.>> Are you okay? >I just read his post, and there was nothing rude about it.--James HawkinsFor once, I agree with James ;-). Gruff, maybe, but not downright rude. -- ThanksTomCheck out this new 3D Instant Messenger called IMVU. It's the best I have seen yet!http://www.imvu.com/catalog/web_registration.php?userId=1547373
crypt32/sip: new test failures
Hi,
../../../tools/runtest -q -P wine -M crypt32.dll -T ../../.. -p
crypt32_test.exe.so sip.c && touch sip.ok
sip.c:176: Test failed: Expected CryptSIPRetrieveSubjectGuid to succeed
sip.c:177: Test failed: Expected ERROR_SUCCESS, got 0x0002
sip.c:179: Test failed: Expected ({c689aab8-8e78-11d0-8c47-00c04fc295ee}), got
({c689aab8-8e78-11d0-8c47-00c04fc295ee}).
sip.c:187: Test failed: Expected CryptSIPRetrieveSubjectGuid to succeed
sip.c:188: Test failed: Expected ERROR_SUCCESS, got 0x0057
sip.c:190: Test failed: Expected ({c689aab8-8e78-11d0-8c47-00c04fc295ee}), got
({c689aab8-8e78-11d0-8c47-00c04fc295ee}).
sip.c:199: Test failed: Expected CryptSIPRetrieveSubjectGuid to succeed
sip.c:200: Test failed: Expected ERROR_SUCCESS, got 0x0057
sip.c:202: Test failed: Expected ({c689aab8-8e78-11d0-8c47-00c04fc295ee}), got
({c689aab8-8e78-11d0-8c47-00c04fc295ee}).
fixme:crypt:CryptSIPLoad ((null) 0 (nil)) stub!
fixme:crypt:CryptSIPLoad ({7b845773-cc00-7ffd--3b933460} 0 (nil)) stub!
fixme:crypt:CryptSIPLoad ({deadbeef-dead-beef-dead-beefdeadbeef} 0 0x33fda0)
stub!
fixme:crypt:CryptSIPLoad ({deadbeef-dead-beef-dead-beefdeadbeef} 0 0x33fda0)
stub!
fixme:crypt:CryptSIPLoad ({c689aaba-8e78-11d0-8c47-00c04fc295ee} 0 0x33fda0)
stub!
fixme:crypt:CryptSIPLoad ({c689aaba-8e78-11d0-8c47-00c04fc295ee} 0 0x33fda0)
stub!
fixme:crypt:CryptSIPLoad ({c689aaba-8e78-11d0-8c47-00c04fc295ee} 1 0x33fda0)
stub!
make[2]: *** [sip.ok] Fehler 9
I did run "wineprefixcreate" before (just in case).
Ciao, Marcus
Re: Can't open DLL's without sudo
On 9/28/06, Paul Wilkinson <[EMAIL PROTECTED]> wrote: What's the point of giving new people attitude? Of course I read the error messages. Are you okay? I just read his post, and there was nothing rude about it. -- James Hawkins
[rsaenh-test]: import&export of a plaintext public key + algID check
* test for importing a PlainPublicKey * test for the correct ALG_ID after the import * test for the correct PlainPublicKey after exporting the key again Karsten rsa1.diff Description: Binary data
RE: Can't open DLL's without sudo
What's the point of giving new people attitude? Of course I read the error messages. Are you okay? -Original Message- From: Vitaliy Margolen [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 5:47 AM To: Paul Wilkinson Cc: wine-devel@winehq.org Subject: Re: Can't open DLL's without sudo This e-mail belongs in wine-user not here. Please read error messages yourself first. Vitaliy Paul Wilkinson wrote: > I'm running wine v 0.9.20 under Fedora Core 5. > > > > I'm trying to get the Syncrosoft License Control Center to run under > wine. for some reason it can only load MFC42.DLL and MSVCRT.DLL if I > put 'sudo' on the command line: > > > > [EMAIL PROTECTED] LCC]$ wine LCC.exe > err:module:import_dll Library MFC42.DLL (which is needed by > L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe") not found > err:module:import_dll Library MSVCRT.dll (which is needed by > L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe") not found > err:module:import_dll Library MSVCRT.dll (which is needed by > L"C:\\windows\\system32\\MSVCP60.dll") not found > err:module:import_dll Library MSVCP60.dll (which is needed by > L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe") not found > err:module:LdrInitializeThunk Main exe initialization for L"C:\\Program > Files\\Syncrosoft\\LCC\\LCC.exe" failed, status c135 > [EMAIL PROTECTED] LCC]$ > > > > The NtOpenFile that tries to open the DLL (in loader.c) is returning > c0022 (ACCESS_DENIED). But the permissions for these DLL's are wide > open. > > > > Any idea what's going on? > > > > - Paul > > > > > > >
Re: Patchwork (was Re: Governance revisited)
Mike McCormack wrote: Ge van Geldorp wrote: My objective is to improve Wine by maximizing the number of patches of acceptable quality. In my opinion, this can be done by: 1) assuring no patches get lost 2) assuring an author gets informed about why his patch is not acceptable in its current form so he can improve it. That sounds good, but it's not reasonable to put the responsibility on Alexandre, as he has enough work already. I have been watching this thread with keen interest. Alexandre does not HAVE to respond to that patch, he can silently ignore it just like he can now. The only difference with Patchwork would be that after a certain time with no comments and no commits, the patch would be removed from the queue and the submitter would get an email warning. regards, Jakob Eriksson
Yesterday's (6/28) Git (gdi32) updates break 64-bit compilation.
The updates in yesterday's Git tree have broken compilation under 64-bit. Previously, it was working. I entered a bugzilla entry for it (http://bugs.winehq.org/show_bug.cgi?id=6304), but thought I would mention it here too - since I think it's a pretty big deal and it doesn't seem that many of the developers here are working under 64-bit (and therefore wouldn't notice the issue). ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./gdi32.spec dispdib.spec.o gdi.exe.spec.o wing.spec.o bidi16.o dispdib.o env.o gdi16.o metafile16.o wing.o bidi.o bitblt.o bitmap.o brush.o clipping.o dc.o dib.o driver.o enhmetafile.o enhmfdrv/bitblt.o enhmfdrv/dc.o enhmfdrv/graphics.o enhmfdrv/init.o enhmfdrv/mapping.o enhmfdrv/objects.o font.o freetype.o gdi_main.o gdiobj.o icm.o mapping.o metafile.o mfdrv/bitblt.o mfdrv/dc.o mfdrv/graphics.o mfdrv/init.o mfdrv/mapping.o mfdrv/objects.o mfdrv/text.o painting.o palette.o path.o pen.o printdrv.o region.oversion.res -o gdi32.dll.so -ladvapi32 -lkernel32 -lntdll /usr/lib/libsicuuc.a /usr/lib/libsicudata.a -lstdc++ -lgcc_s ../../libs/port/libwine_port.a -L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 ld: Relocatable linking with relocations from format elf64-x86-64 (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.n0hnjc.o) is not supported winebuild: ld -m elf_i386 -r failed with status 256 winegcc: ../../tools/winebuild/winebuild failed. make[2]: *** [gdi32.dll.so] Error 2 make[2]: Leaving directory `/data/install/wine/dlls/gdi' make[1]: *** [gdi] Error 2 make[1]: Leaving directory `/data/install/wine/dlls' make: *** [dlls] Error 2 -J
Re: Patchwork (was Re: Governance revisited)
Ge van Geldorp wrote: Actually, that's not how I intended things to work. The automatic removal from the queue would only happen if the patch had a RFC status, i.e. if action is expected from the patch submitter. If the patch is unopposed and just waiting in the queue, it should stay there. It's reasonable to tell a submitter "you seem to have lost interest in this patch, it has been waiting on action from you for [a month, whatever] but nothing has happened, therefore it will be removed from the queue". Sending a warning message "your patch is going to be dropped without explanation" is no improvement over the current situation. Ok, I misunderstood. These things are tricky to comprehend and even harder to discuss. :) // Jakob
Award for solving bug 6183
There is bug in wine, which prevents me to play NFS MW with sound (and even Call of Duty). I would like to offer some money for solving this bug. I dont know how much will be good and i can give you all info from my system to solve this (debug, system info). If you are interested in just reply on my email address. Thanks, Mirek
RFC: dlls/user/tests/win.c fix
The attached patch (sorry, crappy mailer) fixes the win.c failure I was seeing. Is it correct? --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Index: dlls/user/tests/win.c === RCS file: /home/wine/wine/dlls/user/tests/win.c,v retrieving revision 1.87 diff -u -r1.87 win.c --- dlls/user/tests/win.c 4 Aug 2006 19:58:08 - 1.87 +++ dlls/user/tests/win.c 29 Sep 2006 18:18:46 - @@ -2551,7 +2551,7 @@ ok(msg.hwnd == popup && msg.message == WM_LBUTTONUP, "hwnd %p message %04x\n", msg.hwnd, msg.message); ret = PeekMessageA(&msg, 0, 0, 0, PM_REMOVE); -ok(!ret, "message %04x available\n", msg.message); +ok(!ret || msg.message == WM_PAINT, "message %04x available\n", msg.message); ShowWindow(popup, SW_HIDE); while (PeekMessageA(&msg, 0, 0, 0, PM_REMOVE)) DispatchMessageA(&msg);
Re: make test failure #6
On 9/29/06, Juan Lang <[EMAIL PROTECTED]> wrote: Hi James, > make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' > ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p > user32_test.exe.so sysparams.c && touch sysparams.ok > sysparams.c:1471: Test failed: wrong value in registry -1, expected 154 > sysparams.c:1474: Test failed: wrong value in registry -1, expected 0 > sysparams.c:1477: Test failed: wrong value in registry -1, expected 0 > sysparams.c:1480: Test failed: wrong value in registry -1, expected 8 > make[2]: *** [sysparams.ok] Error 4 This, like many other errors, disappears for me when I rerun make test. (I'm not too happy with the 'rerun make test' option, but I don't see people falling all over themselves up to fix the tests, either.) I'm sure you agree with me when I say that these should pass on the first run. I'll have a look at this case, assuming no one else will. -- James Hawkins
make test failure (#7?)
After I run make test a bunch of times to get other failures to disappear, I get this: make[2]: Entering directory `/home/juan/src/wine-20050725/dlls/user/tests' ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so win.c && touch win.ok fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE win.c:2554: Test failed: message 000f available make[2]: *** [win.ok] Error 1 make[2]: Leaving directory `/home/juan/src/wine-20050725/dlls/user/tests' make[1]: *** [user/tests/__test__] Error 2 make[1]: Leaving directory `/home/juan/src/wine-20050725/dlls' make: *** [dlls/__test__] Error 2 --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: make test failure #6
Hi James, > make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' > ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p > user32_test.exe.so sysparams.c && touch sysparams.ok > sysparams.c:1471: Test failed: wrong value in registry -1, expected 154 > sysparams.c:1474: Test failed: wrong value in registry -1, expected 0 > sysparams.c:1477: Test failed: wrong value in registry -1, expected 0 > sysparams.c:1480: Test failed: wrong value in registry -1, expected 8 > make[2]: *** [sysparams.ok] Error 4 This, like many other errors, disappears for me when I rerun make test. (I'm not too happy with the 'rerun make test' option, but I don't see people falling all over themselves up to fix the tests, either.) --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: shdocvw: Make sure BSTR is allocated before calling sink
Hi Cihan, Cihan Altinay wrote: > This fixes bug 6054 and let's MSN Messenger 7 start up. > http://bugs.winehq.org/show_bug.cgi?id=6054 > > --- > dlls/shdocvw/dochost.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/shdocvw/dochost.c b/dlls/shdocvw/dochost.c > index 5bb40e0..8d78a49 100644 > --- a/dlls/shdocvw/dochost.c > +++ b/dlls/shdocvw/dochost.c > @@ -49,11 +49,12 @@ static void navigate_complete(DocHost *T > V_DISPATCH(params+1) = disp; > > V_VT(&url) = VT_BSTR; > -V_BSTR(&url) = This->url; > +V_BSTR(&url) = SysAllocString(This->url); > > call_sink(This->cps.wbe2, DISPID_NAVIGATECOMPLETE2, &dispparams); > call_sink(This->cps.wbe2, DISPID_DOCUMENTCOMPLETE, &dispparams); > > +SysFreeString(This->url); You should free V_BSTR(&url) here, not This->url. Jacek
Re: make test failure
On 9/29/06, Vitaliy Margolen <[EMAIL PROTECTED]> wrote: Michael Stefaniuc wrote: > James Hawkins wrote: >> On 9/28/06, Vitaliy Margolen <[EMAIL PROTECTED]> wrote: >> >>> James Hawkins wrote: On 9/28/06, Paul Vriens <[EMAIL PROTECTED]> wrote: > On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote: >> Hi, >> >> Running make test fails with: >> >> make[2]: Entering directory >>> `/usr/local/src/wine/dlls/comctl32/tests' >> ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p >> comctl32_test.exe.so tab.c && touch tab.ok >> tab.c:184: Test failed: no icon, set size: Expected [44,20] got >>> [56,20] >> tab.c:208: Test failed: no icon, set size: Expected [42,20] got >>> [54,20] >> tab.c:184: Test failed: no icon, set size: Expected [44,20] got >>> [56,20] >> tab.c:208: Test failed: no icon, set size: Expected [42,20] got >>> [54,20] >> tab.c:184: Test failed: no icon, set size: Expected [44,20] got >>> [56,20] >> tab.c:184: Test failed: no icon, set size: Expected [54,20] got >>> [56,20] >> make[2]: *** [tab.ok] Error 6 >> > Succeeds over here. > I know, it succeeds on a lot of machines, but the point is that it shouldn't fail on any machine. >>> Please remove your ~/.wine dir and try again. It seems your metrics are >>> set different. Or your fonts are wrong. >>> >> The tests still fail with a clean .wine. > Yes, i used an empty .wine too. > And you guys have windows like "Arial" font? Any test that uses fonts will not work if you don't have that font or it's not the same metrics as the native one. I don't really know if I have an Arial like font or not. Either the test shouldn't be dependent on a certain font being installed, or we need a --verbose output in configure saying that certain fonts are missing. I have the latest fontforge and freetype installed, pluss msttcorefonts, etc. What else do I need? This is the problem a lot of users are running into. We don't know the magic passphrase that gives us good looking fonts in Wine. I'm a Wine developer of two years, and I still don't know exactly what is required. -- James Hawkins
Re: USER32: Stub implementation of BlockInput
You forgot the patch.. --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: shdocvw(2/2): ignore VT_ERROR arguments to WebBrowser_Navigate2
> Ignoring VT_ERROR just masks a previous error. Hm.. are you sure? These are input arguments, not results. This isn't the only app that gets further with this patch. See also bug 6166. I guess a test case is the only answer. --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: make test failure
Michael Stefaniuc wrote: > James Hawkins wrote: >> On 9/28/06, Vitaliy Margolen <[EMAIL PROTECTED]> wrote: >> >>> James Hawkins wrote: On 9/28/06, Paul Vriens <[EMAIL PROTECTED]> wrote: > On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote: >> Hi, >> >> Running make test fails with: >> >> make[2]: Entering directory >>> `/usr/local/src/wine/dlls/comctl32/tests' >> ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p >> comctl32_test.exe.so tab.c && touch tab.ok >> tab.c:184: Test failed: no icon, set size: Expected [44,20] got >>> [56,20] >> tab.c:208: Test failed: no icon, set size: Expected [42,20] got >>> [54,20] >> tab.c:184: Test failed: no icon, set size: Expected [44,20] got >>> [56,20] >> tab.c:208: Test failed: no icon, set size: Expected [42,20] got >>> [54,20] >> tab.c:184: Test failed: no icon, set size: Expected [44,20] got >>> [56,20] >> tab.c:184: Test failed: no icon, set size: Expected [54,20] got >>> [56,20] >> make[2]: *** [tab.ok] Error 6 >> > Succeeds over here. > I know, it succeeds on a lot of machines, but the point is that it shouldn't fail on any machine. >>> Please remove your ~/.wine dir and try again. It seems your metrics are >>> set different. Or your fonts are wrong. >>> >> The tests still fail with a clean .wine. > Yes, i used an empty .wine too. > And you guys have windows like "Arial" font? Any test that uses fonts will not work if you don't have that font or it's not the same metrics as the native one. Vitaliy.
compiling wine for amd64 on ubuntu dapper 6.06
Hi -- I'm trying to get wine going on my ubuntu dapper installation on an amd 64 box. I have followed the wiki instructions in http://wiki.winehq.org/WineOn64bit for ubuntu and rechecked my work. Two things go wrong: 1. /configure can't find opengl, and produces these messages: configure: WARNING: Wine will be build without OpenGL or Direct3D support configure: WARNING: because something is wrong with the OpenGL setup: configure: WARNING: No OpenGL library found on this system. 2. make depend works, but make all fails with this: LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -foversion.res version.rc ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./gdi32.spec dispdib.spec.o gdi.exe.spec.o wing.spec.o bidi16.o dispdib.o env.o gdi16.o metafile16.o wing.o bidi.o bitblt.o bitmap.o brush.o clipping.o dc.o dib.o driver.o enhmetafile.o enhmfdrv/bitblt.o enhmfdrv/dc.o enhmfdrv/graphics.o enhmfdrv/init.o enhmfdrv/mapping.o enhmfdrv/objects.o font.o freetype.o gdi_main.o gdiobj.o icm.o mapping.o metafile.o mfdrv/bitblt.o mfdrv/dc.o mfdrv/graphics.o mfdrv/init.o mfdrv/mapping.o mfdrv/objects.o mfdrv/text.o painting.o palette.o path.o pen.o printdrv.o region.oversion.res -o gdi32.dll.so -ladvapi32 -lkernel32 -lntdll /usr/lib/libsicuuc.a /usr/lib/libsicudata.a -lstdc++ -lgcc_s ../../libs/port/libwine_port.a -L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 ld: Relocatable linking with relocations from format elf64-x86-64 (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.ArPHdq.o) is not supported winebuild: ld -m elf_i386 -r failed with status 256 winegcc: ../../tools/winebuild/winebuild failed. make[2]: *** [gdi32.dll.so] Error 2 make[2]: Leaving directory `/tmp/wine-0.9.22/dlls/gdi' make[1]: *** [gdi] Error 2 make[1]: Leaving directory `/tmp/wine-0.9.22/dlls' make: *** [dlls] Error 2 I'm not sure what to do now. Any feedback/suggestions would be appreciated.
Re: [D3D9] Remove const qualifier on state_test data.
Ivan Gyurdiev wrote:
> Type: Cleanup
>
> Why:
> The const qualifier is unnecessarily restrictive.
> I intend to allocate and free such data on the heap in a future patch.
> Instead, const should be primarily used on function parameters.
Question: do you realy have to use void pointers? Void pointers are
compatible with every pointer type and thus will disable the type
checking of the compiler. Also you do not need to to cast a rvalue to
void * if the type of the lvalue is void *.
bye
michael
> ---
> dlls/d3d9/tests/stateblock.c | 40
> 1 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/dlls/d3d9/tests/stateblock.c b/dlls/d3d9/tests/stateblock.c
> index 65a11e6..68b431a 100644
> --- a/dlls/d3d9/tests/stateblock.c
> +++ b/dlls/d3d9/tests/stateblock.c
> @@ -105,20 +105,20 @@ typedef struct state_test {
> * as the default data, but a write can have side effects.
> * The initial data is tested first, before any writes take place
> * The default data can be tested after a write */
> -const void* initial_data;
> +void* initial_data;
>
> /* The default data is the standard state to compare
> * against, and restore to */
> -const void* default_data;
> +void* default_data;
>
> /* The test data is the experiment data to try
> * in - what we want to write
> * out - what windows will actually write (not necessarily the same) */
> -const void* test_data_in;
> -const void* test_data_out;
> +void* test_data_in;
> +void* test_data_out;
>
> /* The poison data is the data to preinitialize the return buffer to */
> -const void* poison_data;
> +void* poison_data;
>
> /* Return buffer */
> void* return_data;
> @@ -562,11 +562,11 @@ static void shader_constants_queue_test(
> shader_constant_arg* arg = buffer;
> shader_constant_data* return_data = (shader_constant_data*) (arg + 1);
>
> -test->test_data_in = &shader_constant_test_data;
> -test->test_data_out = &shader_constant_test_data;
> -test->default_data = &shader_constant_default_data;
> -test->initial_data = &shader_constant_default_data;
> -test->poison_data = &shader_constant_poison_data;
> +test->test_data_in = (void*) &shader_constant_test_data;
> +test->test_data_out = (void*) &shader_constant_test_data;
> +test->default_data = (void*) &shader_constant_default_data;
> +test->initial_data = (void*) &shader_constant_default_data;
> +test->poison_data = (void*) &shader_constant_poison_data;
> test->return_data = return_data;
> test->data_size = sizeof(shader_constant_data);
> test->set_handler = shader_constant_set_handler;
> @@ -697,11 +697,11 @@ static void lights_queue_test(
> light_arg* arg = buffer;
> light_data* return_data = (light_data*) (arg + 1);
>
> -test->test_data_in = &light_test_data_in;
> -test->test_data_out = &light_test_data_out;
> -test->default_data = &light_default_data;
> -test->initial_data = &light_initial_data;
> -test->poison_data = &light_poison_data;
> +test->test_data_in = (void*) &light_test_data_in;
> +test->test_data_out = (void*) &light_test_data_out;
> +test->default_data = (void*) &light_default_data;
> +test->initial_data = (void*) &light_initial_data;
> +test->poison_data = (void*) &light_poison_data;
> test->return_data = return_data;
> test->data_size = sizeof(light_data);
> test->set_handler = light_set_handler;
> @@ -856,11 +856,11 @@ static void transform_queue_test(
> {
> transform_data* return_data = buffer;
>
> -test->test_data_in = &transform_test_data;
> -test->test_data_out = &transform_test_data;
> -test->default_data = &transform_default_data;
> -test->initial_data = &transform_default_data;
> -test->poison_data = &transform_poison_data;
> +test->test_data_in = (void*) &transform_test_data;
> +test->test_data_out = (void*) &transform_test_data;
> +test->default_data = (void*) &transform_default_data;
> +test->initial_data = (void*) &transform_default_data;
> +test->poison_data = (void*) &transform_poison_data;
> test->return_data = return_data;
> test->data_size = sizeof(transform_data);
> test->set_handler = transform_set_handler;
--
Michael Stefaniuc Tel.: +49-711-96437-199
Sr. Network EngineerFax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
Re: make test failure
James Hawkins wrote: > On 9/28/06, Vitaliy Margolen <[EMAIL PROTECTED]> wrote: > >> James Hawkins wrote: >> > On 9/28/06, Paul Vriens <[EMAIL PROTECTED]> wrote: >> >> On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote: >> >> > Hi, >> >> > >> >> > Running make test fails with: >> >> > >> >> > make[2]: Entering directory >> `/usr/local/src/wine/dlls/comctl32/tests' >> >> > ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p >> >> > comctl32_test.exe.so tab.c && touch tab.ok >> >> > tab.c:184: Test failed: no icon, set size: Expected [44,20] got >> [56,20] >> >> > tab.c:208: Test failed: no icon, set size: Expected [42,20] got >> [54,20] >> >> > tab.c:184: Test failed: no icon, set size: Expected [44,20] got >> [56,20] >> >> > tab.c:208: Test failed: no icon, set size: Expected [42,20] got >> [54,20] >> >> > tab.c:184: Test failed: no icon, set size: Expected [44,20] got >> [56,20] >> >> > tab.c:184: Test failed: no icon, set size: Expected [54,20] got >> [56,20] >> >> > make[2]: *** [tab.ok] Error 6 >> >> > >> >> Succeeds over here. >> >> >> > >> > I know, it succeeds on a lot of machines, but the point is that it >> > shouldn't fail on any machine. >> > >> Please remove your ~/.wine dir and try again. It seems your metrics are >> set different. Or your fonts are wrong. >> > > The tests still fail with a clean .wine. Yes, i used an empty .wine too. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: shdocvw(2/2): ignore VT_ERROR arguments to WebBrowser_Navigate2
Juan Lang wrote:
> Combined with the first patch, I'm able to log in with Skype 2.6 beta.
>
> ChangeLog: ignore VT_ERROR arguments to WebBrowser_Navigate2
Ignoring VT_ERROR just masks a previous error.
bye
michael
> Index: dlls/shdocvw/webbrowser.c
> ===
> RCS file: /home/wine/wine/dlls/shdocvw/webbrowser.c,v
> retrieving revision 1.65
> diff -u -r1.65 webbrowser.c
> --- dlls/shdocvw/webbrowser.c 25 Sep 2006 19:46:43 - 1.65
> +++ dlls/shdocvw/webbrowser.c 29 Sep 2006 00:55:46 -
> @@ -675,7 +675,7 @@
> if(V_VT(URL) != VT_BSTR)
> return E_INVALIDARG;
>
> -if(PostData && V_VT(PostData) != VT_EMPTY) {
> +if(PostData && V_VT(PostData) != VT_EMPTY && V_VT(PostData) != VT_ERROR)
> {
> if(V_VT(PostData) != (VT_ARRAY | VT_UI1)
> || V_ARRAY(PostData)->cDims != 1) {
> WARN("Invalid PostData\n");
> @@ -686,7 +686,7 @@
> post_data_len = V_ARRAY(PostData)->rgsabound[0].cElements;
> }
>
> -if(Headers && V_VT(Headers) != VT_EMPTY) {
> +if(Headers && V_VT(Headers) != VT_EMPTY && V_VT(Headers) != VT_ERROR) {
> if(V_VT(Headers) != VT_BSTR)
> return E_INVALIDARG;
>
>
>
>
>
>
--
Michael Stefaniuc Tel.: +49-711-96437-199
Sr. Network EngineerFax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
Re: Governance Ideas
Robert Lunnon wrote: "Community Focused Process" means what it says, develop a process which is centred on the community the project serves. This requires the project to answer some introspective questions 1. Who "owns" Wine, does wine belong to A.) Alexandre, or B) the community it serves. A) Alexandre is a benelovent dictator. He manages Wine with the interests of "the community" in mind, as he sees them. 1. Answer the questions about the "ownership" of wine and identify the community it serves. Determine the right of the community to be involved is setting wines direction IE The Bill of rights I mentioned before (for each community Developers VS Users etc). Your "bill of rights" is the Wine license, the LGPL. 2. Alexandre documents the exact logic he uses to determine patch acceptability which becomes the patch acceptance policy in the interim. It's very likely impossible to write that down. If you don't agree with me, please write down your proposal. 3. The project develops a community process for establishing project direction and maintaining the patch acceptance policy which includes stakeholders elected from the "owners" IE communities with a stakeholding in wine NetBSD is a project that is (was?) run by committees: http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html If you want Wine to be run by a committee, how about creating your own fork so you can run it as you see fit? Mike
Re: make test failure #3
On Thursday 28 September 2006 20:55, James Hawkins wrote: > Hi, > > make[2]: Entering directory `/usr/local/src/wine/dlls/shell32/tests' > ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p > shell32_test.exe.so shlfileop.c && touch shlfileop.ok > shlfileop.c:168: Test failed: The requested file does not exist, ret=3 > make[2]: *** [shlfileop.ok] Error 1 A trace of this can be found in http://www.winehq.org/pipermail/wine-devel/2006-September/051141.html Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpC6zcaN5pQD.pgp Description: PGP signature
