February 2009 - Wine-Devel - list.winehq.org

Re: msctf crosstest build failed

by Nikolay Sivov

Nicolas Le Cam wrote: > 2009/2/19 Nikolay Sivov <bunglehead(a)gmail.com>: > >> Nicolas Le Cam wrote: >> >>> 2009/2/18 Nikolay Sivov <bunglehead(a)gmail.com>: >>> >>> >>>> Building today crosstests I've got: >>>> >>>> i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include >>>> -g -O2 -o inputprocessor.cross.o inputprocessor.c >>>> i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include >>>> -g -O2 -o testlist.cross.o testlist.c >>>> i586-mingw32msvc-gcc inputprocessor.cross.o testlist.cross.o -o >>>> msctf_crosstest.exe -L../../../dlls -L../../../dlls/uuid >>>> -L../../../dlls/ole32 -L../../../dlls/user32 -L../../../dlls/kernel32 >>>> -luuid -lole32 -luser32 -lkernel32 >>>> inputprocessor.cross.o: In function `initialize': >>>> /home/mrlarch/wine-git/dlls/msctf/tests/inputprocessor.c:41: undefined >>>> reference to `_CLSID_TF_InputProcessorProfiles' >>>> collect2: ld returned 1 exit status >>>> make[2]: *** [msctf_crosstest.exe] Error 1 >>>> make[2]: Leaving directory `/home/mrlarch/wine-git/dlls/msctf/tests' >>>> make[1]: *** [msctf/tests/__crosstest__] Error 2 >>>> make[1]: Leaving directory `/home/mrlarch/wine-git/dlls' >>>> make: *** [dlls/__crosstest__] Error 2 >>>> >>>> This outputs after: >>>> make clean >>>> ./configure >>>> make depend && make >>>> make crosstest >>>> >>>> What seems to be a problem? >>>> >>>> >>>> >>>> >>>> >>> Same here. Can't find a solution. >>> Perhaps it's because libuuid exports the CLSID as >>> CLSID_TF_InputProcessorProfiles instead of >>> _CLSID_TF_InputProcessorProfiles but I don't know how to fix. >>> >>> >> It's normal, is a kind of naming convention, don't know how to call it >> right, but it's ok. >> >>> Does building it with winegcc instead of ar / ranlib could fix the problem >>> ? >>> >>> >> Native test builds without any problem. What do you mean? >> As I checked uuid isn't imported anywhere else in test suite, inline guid >> definitions used instead. >> So if nobody knows why this happens I propose to patch msctf/tests not to >> use uuid. >> Now I'm setting up a system with rather fresh Lenny, so you could send this >> patch. >> >> >> > > Just found that Alexandre committed something related to that last > year. It seems to be a problem with MingW, see [1]. > I will send a fix this evening. > > > [1] http://source.winehq.org/git/wine.git/?a=commit;h=79c64acc7b5f9f9de07592fec… > > Ok, thanks.

Feb. 19, 2009

Re: msctf crosstest build failed

by Nicolas Le Cam

2009/2/19 Nikolay Sivov <bunglehead(a)gmail.com>: > Nicolas Le Cam wrote: >> >> 2009/2/18 Nikolay Sivov <bunglehead(a)gmail.com>: >> >>> >>> Building today crosstests I've got: >>> >>> i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include >>> -g -O2 -o inputprocessor.cross.o inputprocessor.c >>> i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include >>> -g -O2 -o testlist.cross.o testlist.c >>> i586-mingw32msvc-gcc inputprocessor.cross.o testlist.cross.o -o >>> msctf_crosstest.exe -L../../../dlls -L../../../dlls/uuid >>> -L../../../dlls/ole32 -L../../../dlls/user32 -L../../../dlls/kernel32 >>> -luuid -lole32 -luser32 -lkernel32 >>> inputprocessor.cross.o: In function `initialize': >>> /home/mrlarch/wine-git/dlls/msctf/tests/inputprocessor.c:41: undefined >>> reference to `_CLSID_TF_InputProcessorProfiles' >>> collect2: ld returned 1 exit status >>> make[2]: *** [msctf_crosstest.exe] Error 1 >>> make[2]: Leaving directory `/home/mrlarch/wine-git/dlls/msctf/tests' >>> make[1]: *** [msctf/tests/__crosstest__] Error 2 >>> make[1]: Leaving directory `/home/mrlarch/wine-git/dlls' >>> make: *** [dlls/__crosstest__] Error 2 >>> >>> This outputs after: >>> make clean >>> ./configure >>> make depend && make >>> make crosstest >>> >>> What seems to be a problem? >>> >>> >>> >>> >> >> Same here. Can't find a solution. >> Perhaps it's because libuuid exports the CLSID as >> CLSID_TF_InputProcessorProfiles instead of >> _CLSID_TF_InputProcessorProfiles but I don't know how to fix. >> > > It's normal, is a kind of naming convention, don't know how to call it > right, but it's ok. >> >> Does building it with winegcc instead of ar / ranlib could fix the problem >> ? >> > > Native test builds without any problem. What do you mean? > As I checked uuid isn't imported anywhere else in test suite, inline guid > definitions used instead. > So if nobody knows why this happens I propose to patch msctf/tests not to > use uuid. > Now I'm setting up a system with rather fresh Lenny, so you could send this > patch. > > Just found that Alexandre committed something related to that last year. It seems to be a problem with MingW, see [1]. I will send a fix this evening. [1] http://source.winehq.org/git/wine.git/?a=commit;h=79c64acc7b5f9f9de07592fec…

Feb. 19, 2009

Re: Win to Lin Library Wrapper

by Jérôme Gardou

> > Gentoo users still have to set the +opengl use flag... That's where most of > the complaints came from. > > The other aspect is that even software GL isn't available when you're using > Xvnc or similar servers. > > > To be honest, I prefer the second argument over the first one :-)

Feb. 19, 2009

Re: Status of USB driver support?

by emiliano esposito

Alexander Morozov ha scritto: >> git clone git://source.winehq.org/git/wine.git ~/wine-git >> git-am 0001... >> git-am 0002... >> > > You should run tools/make_makefiles before configuring. Thanks. I redid it from scratch, and imported the relevant keys directly from windows. Now this is what I get after launching the program: fixme:ntoskrnl:KeInitializeSpinLock stub: 0x129824 wine: Call from 0x7ee2e8b0 to unimplemented function usbd.sys.USBD_GetUSBDIVersion, aborting wine: Unimplemented function usbd.sys.USBD_GetUSBDIVersion called at address 0x7ee2e8b0 (thread 0022), starting debugger... Unhandled exception: unimplemented function usbd.sys.USBD_GetUSBDIVersion called in 32-bit code (0x7ee2e923) Then a lot of debug info follows, register dumps and so on. After that, the program continues normally. Don't know if it would be worth posting, please let me know.

Feb. 19, 2009

Re: msctf crosstest build failed

by Nicolas Le Cam

2009/2/18 Nikolay Sivov <bunglehead(a)gmail.com>: > Building today crosstests I've got: > > i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include > -g -O2 -o inputprocessor.cross.o inputprocessor.c > i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include > -g -O2 -o testlist.cross.o testlist.c > i586-mingw32msvc-gcc inputprocessor.cross.o testlist.cross.o -o > msctf_crosstest.exe -L../../../dlls -L../../../dlls/uuid > -L../../../dlls/ole32 -L../../../dlls/user32 -L../../../dlls/kernel32 > -luuid -lole32 -luser32 -lkernel32 > inputprocessor.cross.o: In function `initialize': > /home/mrlarch/wine-git/dlls/msctf/tests/inputprocessor.c:41: undefined > reference to `_CLSID_TF_InputProcessorProfiles' > collect2: ld returned 1 exit status > make[2]: *** [msctf_crosstest.exe] Error 1 > make[2]: Leaving directory `/home/mrlarch/wine-git/dlls/msctf/tests' > make[1]: *** [msctf/tests/__crosstest__] Error 2 > make[1]: Leaving directory `/home/mrlarch/wine-git/dlls' > make: *** [dlls/__crosstest__] Error 2 > > This outputs after: > make clean > ./configure > make depend && make > make crosstest > > What seems to be a problem? > > > Same here. Can't find a solution. Perhaps it's because libuuid exports the CLSID as CLSID_TF_InputProcessorProfiles instead of _CLSID_TF_InputProcessorProfiles but I don't know how to fix. Does building it with winegcc instead of ar / ranlib could fix the problem ?

Feb. 19, 2009

Re: Win to Lin Library Wrapper

by Stefan Dösinger

> This might be a silly question, but isn't MESA here just for it : > providing openGL functionality to sytems that don't have good hardware? > And wasn't it planned somewhere to split together wined3d and winex11 > (not related to the question here, but just curious :) ) Gentoo users still have to set the +opengl use flag... That's where most of the complaints came from. The other aspect is that even software GL isn't available when you're using Xvnc or similar servers.

Feb. 19, 2009

Re: revert of a6c07ffba4b2b37d01affb4c39f032bb5f8d34bf

by Francois Gouget

A little bit of explanation would be nice... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ La terre est une bêta...

Feb. 19, 2009

Re: Win to Lin Library Wrapper

by Jérôme Gardou

Stefan Dösinger a écrit : > Am Mittwoch, 18. Februar 2009 23:47:47 schrieb Jérôme Gardou: > >> As of ddraw, wouldn't it be possible to write it on top of d3d9, as it >> is already done with wined3d. >> > That will screw non-opengl ddraw rendering, which the VNC/remote X/old > card/bad driver users will not really like. WineD3D currently has two surface > implementations, one for GL based rendering and one for SW emulation(2D only) > > /me remembers the uproar when the ddraw rewrite broke the ability to compile > ddraw without GL headers. (gentoo useflags OMG!!!) > This might be a silly question, but isn't MESA here just for it : providing openGL functionality to sytems that don't have good hardware? And wasn't it planned somewhere to split together wined3d and winex11 (not related to the question here, but just curious :) )

Feb. 19, 2009

Re: Need help on couple of patches

by Juan Lang

> But I've looked through listview tests and it seems to be quite simple > (much simplier than WinAPI and C appeared to me at the very start :) > ), so I hope to figure it out. If you get stuck, send what you have and ask for help. We're trying to encourage you to keep working on it, so your patch gets accepted :) --Juan

Feb. 19, 2009

Re: Need help on couple of patches

by Igor Tarasov

> The key is to see what happens and if it is what you expected. Can this > also be emulated in any version of Windows to verify this is what > happens there? I hope that clicking listview header and then bumping message to the application happens in any Windows version. I hope. Anyway, I do understand WHAT I have to do pretty well. What I do not understand well is HOW I do that. You know, you may understand the language, but thats not enough to speak in it. Especially not patching something, but writing something from scratch (as with test). I've stated many times that I am not C programmer (though programming is my job, but I do web stuff). And the only reason why I started patching wine is that several very important for me bugs were not fixed for quite long, so I started digging into it. But I've looked through listview tests and it seems to be quite simple (much simplier than WinAPI and C appeared to me at the very start :) ), so I hope to figure it out.

Feb. 19, 2009