- Wine-devel - list.winehq.org

ppdebug
by Michael Sauer 29 Nov '02

29 Nov '02

since some versions of wine (actually i checked today's version out) I get the following error messages while compiling (i ignored them the last two times, assuming i want ppdebug set to 0 and patching the code that way) : gcc -g -O2 -Wall -mpreferred-stack-boundary=2 -o widl header.o proxy.o utils.o widl.o y.tab.o lex.yy.o -L../../tools/wpp -lwpp -L../../library -lwine -L../../u nicode -lwine_unicode -lfl ../../tools/wpp/libwpp.a(wpp.o)(.text+0x14b): In function `wpp_set_debug': /opt/src/build/wine/tools/wpp/wpp.c:74: undefined reference to `ppdebug' ../../tools/wpp/libwpp.a(lex.yy.o)(.text+0x3533): In function `push_buffer': /opt/src/build/wine/tools/wpp/./ppl.l:1147: undefined reference to `ppdebug' ../../tools/wpp/libwpp.a(lex.yy.o)(.text+0x38c0): In function `pop_buffer': /opt/src/build/wine/tools/wpp/./ppl.l:1232: undefined reference to `ppdebug' collect2: ld returned 1 exit status make[2]: *** [widl] Error 1 make[2]: Leaving directory `/opt/src/build/wine/tools/widl' make[1]: *** [widl] Error 2 make[1]: Leaving directory `/opt/src/build/wine/tools' make: *** [tools] Error 2

1 0

RE: msvcmaker
by Patrik Stridvall 29 Nov '02

29 Nov '02

> program/winetest doesn't exist anymore. Creating it empty is > enough for > msvcmaker to work, but is not the proper fix. I don't have the time > right now to check all the winetest references in msvcmaker > (there are > more than i thought). Working on it.

1 0

Re: COM vtable inconsistencies with g++ (was SIGSEGV in IDirectDrawImpl_EnumDisplayModes)
by Dan Kegel 29 Nov '02

29 Nov '02

Sylvain wrote: >> Thanks! >> It works fine with the version 2.96 I use. > Do you know RedHat's gcc 2.96 has SERIOUS bugs and that its support has > been totally dropped ? Support has been dropped by whom? Not Red Hat; they are still releasing updates for gcc-2.96-RH. The latest was 18 days ago, https://rhn.redhat.com/errata/RHBA-2002-200.html > It's update time. I agree, gcc 3.2[.1] is a better choice than gcc-2.96-RH these days. It is very close to compliance with the C++ ABI, and it's an official Gnu release rather than a vendor snapshot. (I'm building wine for the first time with gcc3.2 today, I hope I'm right about it being a better choice :-) - Dan

1 0

msvcmaker
by Vincent Béron 29 Nov '02

29 Nov '02

Hi all, program/winetest doesn't exist anymore. Creating it empty is enough for msvcmaker to work, but is not the proper fix. I don't have the time right now to check all the winetest references in msvcmaker (there are more than i thought). Vincent

1 0

RE: Janitorial Projects
by Patrik Stridvall 29 Nov '02

29 Nov '02

> What we need next: > 1. a way to run all tests. A batch file would do the job nicely. > Patrik, can that be added to msvcmaker? Planned but not done. However, since you asked for it, I will look into it right away.

1 0

RE: Winapi_check warnings
by Patrik Stridvall 29 Nov '02

29 Nov '02

> On November 29, 2002 01:53 pm, Patrik Stridvall wrote: > > Not really, you haven't run ./configure on that tree have you? > > winapi_check assumes that this is done, but I can fix it if > > it irritates you. > > Oh, I have separate src/build trees, and I was running it in > the source tree. In fact, I _have_ to run it in the source > tree, and then I get the errors... OK. I will fix winapi_check to support that.

1 0

Re: somebody help me identify this bug please
by Jeff Smith 29 Nov '02

29 Nov '02

Is it only characters with the acute accent? Is it that your are attempting this using 'dead key' entry on a Spanish keyboard? If this is the case, the problem may be in a recent correction to the Spanish keyboard layout. I will work on this some more when I get a chance, but hopefully someone else will find something sooner. -- Jeff S >From: "ezra daniel" <ezra_daniel(a)hotmail.com> > >Hello, > >At work I use Lotus Notes under Wine. > >I downloaded compiled and installed the new wine version 20021125 and I am >no longer able to type accecented valves, like á é í ó ú. > >Ñ can be typed though correctly. > >With the other version 20021031 I could type accented valves.In fact I went >back to using the older version and worked again so it is obvious it is a >problem in the new wine version. > >Though I am a newbie and know nothing of developing, but I would like to >submit the bug to the proper person so it fixes it back again but I dont >know which section of wine or person deals with this character typing >problem. > >Can anyone point me in the right direction? Thanks in advance. > >-daniel >http://www.debian-gnu.com _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

1 0

RE: Winapi_check warnings
by Patrik Stridvall 29 Nov '02

29 Nov '02

> Hi Patrik, > > I get these hundreds of warnings about "config.h": [snip] > First of all, I think they are bogus. Not really, you haven't run ./configure on that tree have you? winapi_check assumes that this is done, but I can fix it if it irritates you. > Second, if I specify the > --cross-call-win32-win16 flag, I expect to see only the problems > I am asking for, no? Shouldn't we silence all other warnings, if > we ask for something in particular? There is a --none option. winapi_check --none --cross-call-win32-win16 It doesn't always work though. Beware. However I fixed --cross-call-win32-win16 to support with my last patch, since I assumed somebody would ask. I was right it seems. Presumably you want the --progress option on as well: winapi_check --none --progress --cross-call-win32-win16

2 1

Winapi_check warnings
by Dimitrie O. Paun 29 Nov '02

29 Nov '02

Hi Patrik, I get these hundreds of warnings about "config.h": [dimi(a)dimi wine.src]$ tools/winapi_check/winapi_check --cross-call-win32-win16 dlls/d3d8/d3d8_private.h: #include "config.h" is not a local include dlls/ddraw/d3ddevice/main.h: #include "config.h" is not a local include dlls/ddraw/direct3d/main.h: #include "config.h" is not a local include controls/desktop.c: #include "config.h": file not found controls/desktop.c: #include "config.h" is not a local include controls/edit.c: #include "config.h": file not found controls/edit.c: #include "config.h" is not a local include controls/icontitle.c: #include "config.h": file not found controls/icontitle.c: #include "config.h" is not a local include controls/menu.c: #include "config.h": file not found controls/menu.c: #include "config.h" is not a local include dlls/advapi32/advapi.c: #include "config.h": file not found First of all, I think they are bogus. Second, if I specify the --cross-call-win32-win16 flag, I expect to see only the problems I am asking for, no? Shouldn't we silence all other warnings, if we ask for something in particular? -- Dimi.

1 0

RE: [RFC] Wine headers
by Patrik Stridvall 29 Nov '02

29 Nov '02

> Alexandre, > > Patrik brought up the header location sometime ago, in this thread: > http://www.winehq.com/hypermail/wine-devel/2002/10/index.html#540 > > At the time, I thought it is a bit premature, that we have other > things to do. Now I realize that this is one of those highly visible > external things, that would be a _lot_ better to fix before people > start using Winelib. Otherwise will piss people off when we change, > or we will not change because people are already using the headers. True. > Both versions are not good, and I think we can fix them now without > too much pain. > > Here is my proposal: > ${prefix}/include/win32 -- standard Win32 headers > ${prefix}/include/msvcrt -- MS Visual C Runtime library > ${prefix}/include/wine -- Wine specific headers > > It is simple (to understand & implement), clean, and pretty. > And I think it solved Patrik's problem (even if I can't quite > understand what the problem is from the first message :)), It not easy to mix different flavours of the Win32 headers because of include problems. The problem is that is you have since we include wine specific files like: #include "wine/debug.h" we need to have a include path like -I${prefix}/include However now since the Wine version of the standard Win32 header are in ${prefix}/include we get them included as well if we do -I${prefix}/include So if we do for example -I/opt/microsoft/windows/include we get header include collisions. Sure with GNU C on Linux (and presumably) on Windows we can fix that by specifing a correct include order. However with Microsoft C++ we can't do it in a portable way. With your suggestion above we can, so I like it. :-) > plus a bunch of other things (like making it easy to use other > headers for the Win32 API, etc). And best of all, it seems to > be easily implementable, no? "mv" is your friend however the CVS versioning doesn't like it though...

2 1