June 2011 - Wine-Devel - list.winehq.org

Re: GSoC: dinput8 Action Mapping

by Lucas Zawacki

Hey guys, how are you doing? I've got some patches for you. The first is a refactoring of the BuildActionMap implementations for keyboard and mouse. I think with 'semantic_to_obj_id' the mapping is pretty much correct for keyboard and mouse and it's being done "the right way". The second patch is much like one I sent some time ago, it's SetActionMap for keyboard and mouse, this time (hopefully) with the dataformat stuff done right too. I've split it up in a third patch, which implements the "action mapping" per se. Anyway, tomorrow I'll code some mouse tests to be sure that this is working. Cheers

June 30, 2011

Re: wine bug 27600

by Vincas Miliūnas

On 06/30/2011 02:19 AM, wylda(a)volny.cz wrote: >> There is some garbage added to the patch code, I >> suspect that the way >> you downloaded the patch corrupted it. >> >> I wrote a bash script that will download the >> patches correctly and apply >> them: >> >> git clean -fd >> git reset --hard origin/master >> for i in 75876 75883 75878 75882 75881 75884 75877 75879 75880 >> do >> wget http://source.winehq.org/patches/data/$i -O >> /tmp/raw-$i.patch >> git apply /tmp/raw-$i.patch >> done >> ./tools/make_requests > > Even before i used wget for downloads & patch -p1. Anyway i gave > your script a chance, but i got during the compilation: > > > gcc -c -I. -I. -I../include -I../include -D__WINESRC__ -Wall -pipe > -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body > -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith > -Wlogical-op -g -O2 -o raw_input.o raw_input.c > > In file included from raw_input.c:28: > > ../include/winternl.h:2361: error: expected declaration specifiers > or ‘...’ before ‘va_list’ > > ../include/winternl.h:2531: error: expected declaration specifiers > or ‘...’ before ‘va_list’ > > ../include/winternl.h:2532: error: expected declaration specifiers > or ‘...’ before ‘va_list’ > > In file included from raw_input.c:29: > > ../include/winbase.h:1578: error: expected declaration specifiers or > ‘...’ before ‘va_list’ > > ../include/winbase.h:1579: error: expected declaration specifiers or > ‘...’ before ‘va_list’ > > make[1]: *** [raw_input.o] Error 1 > > make[1]: Leaving directory `/build/wine-git_build/server' > > make: *** [server] Error 2 > > Ok, try with a modified header: git clean -fd git reset --hard origin/master for patch in \ 0001-user32-tests-Added-client-side-raw-input-function-te.patch \ 0002-user32-Added-DefRawInputProc-implementation-try-10.patch \ 0003-server-user32-Added-GetRawInputDeviceList-implementa.patch \ 0004-server-user32-Added-GetRawInputDeviceInfoW-implement.patch \ 0005-user32-Added-GetRawInputDeviceInfoA-implementation-t.patch \ 0006-server-user32-Added-GetRegisteredRawInputDevices-imp.patch \ 0007-server-user32-Added-RegisterRawInputDevices-implemen.patch \ 0008-user32-Added-GetRawInputBuffer-implementation-try-10.patch \ 0009-server-user32-Added-GetRawInputData-implementation-t.patch do wget http://dl.dropbox.com/u/6901628/$patch -O /tmp/$patch git apply /tmp/$patch done ./tools/make_requests

June 30, 2011

Re: [PATCH 3/3] d3dx9/tests: Implemented Draw and DrawTransform tests for ID3DXLine.

by Charles Welton

Forgot that this patch was based on the previous one I sent. I should probably resend when and if the others are committed. On 06/29/2011 10:20 PM, Marvin wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=12105 > > Your paranoid android. > > > === WINEBUILD (build) === > Patch failed to apply -- Charles Welton

June 29, 2011

Re: [PATCH 3/3] d3dx9/tests: Implemented Draw and DrawTransform tests for ID3DXLine.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=12105 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

June 29, 2011

Re: [2/2] d3dx9_36: Implement and add tests for D3DXFloat16To32Array.

by Matteo Bruni

2011/6/29 Misha Koshelev <misha680(a)gmail.com>: > --- ... > + else return sgn * powf(2, -14.0f) * ((float)m / 1024.0f); ... > + return sgn * powf(2, (float)e - 15.0f) * (1.0f + ((float)m / 1024.0f)); I think you don't need the explicit casts here, the values should be automatically promoted to floats as the other operand is a float as well.

June 29, 2011

Re: wine bug 27600

by wylda＠volny.cz

> There is some garbage added to the patch code, I > suspect that the way > you downloaded the patch corrupted it. > > I wrote a bash script that will download the > patches correctly and apply > them: > > git clean -fd > git reset --hard origin/master > for i in 75876 75883 75878 75882 75881 75884 75877 75879 75880 > do > wget http://source.winehq.org/patches/data/$i -O > /tmp/raw-$i.patch > git apply /tmp/raw-$i.patch > done > ./tools/make_requests Even before i used wget for downloads & patch -p1. Anyway i gave your script a chance, but i got during the compilation: gcc -c -I. -I. -I../include -I../include -D__WINESRC__ -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o raw_input.o raw_input.c In file included from raw_input.c:28: ../include/winternl.h:2361: error: expected declaration specifiers or ‘...’ before ‘va_list’ ../include/winternl.h:2531: error: expected declaration specifiers or ‘...’ before ‘va_list’ ../include/winternl.h:2532: error: expected declaration specifiers or ‘...’ before ‘va_list’ In file included from raw_input.c:29: ../include/winbase.h:1578: error: expected declaration specifiers or ‘...’ before ‘va_list’ ../include/winbase.h:1579: error: expected declaration specifiers or ‘...’ before ‘va_list’ make[1]: *** [raw_input.o] Error 1 make[1]: Leaving directory `/build/wine-git_build/server' make: *** [server] Error 2

June 29, 2011

Re: Bad_Pool_Header

by Austin English

On Wed, Jun 29, 2011 at 03:01, Keith Muir <foxbat3(a)gmail.com> wrote: > Hi, > > Been trying to run wine tests from http://test.winehq.org/data/ but every > time I try this for about the last half dozen versions I get a blue screen > and bad pool header > any suggestions? I try to support the project by doing test runs and > updating the appdb. What video card/OS/drivers? Can you narrow it down to the first bad/last working winetest? Cheers, Austin

June 29, 2011

Re: wine bug 27600

by Vincas Miliūnas

On 06/30/2011 12:22 AM, wylda(a)volny.cz wrote: >> The patch is rebased against today's commits - >> http://dl.dropbox.com/u/6901628/raw.patch > The good news is, that this combo patch successfully compiles here. > > The bad new is, that today's 9 newly sent patches still fails here. > I did regression test above them and 1of9 + 2of9 successfully > compiles here, in other word first bad "commit" is 3of9. > > Adding config.log and output of ./configure (each as vanilla and > patched for comparison). > > > Regards, > W. > > > The 3th patch adds the c file for wineserver. ./configure log just shows that you have way more devel packages installed then me :) There is some garbage added to the patch code, I suspect that the way you downloaded the patch corrupted it. I wrote a bash script that will download the patches correctly and apply them: git clean -fd git reset --hard origin/master for i in 75876 75883 75878 75882 75881 75884 75877 75879 75880 do wget http://source.winehq.org/patches/data/$i -O /tmp/raw-$i.patch git apply /tmp/raw-$i.patch done ./tools/make_requests

June 29, 2011

Re: wine bug 27600

by wylda＠volny.cz

> > The patch is rebased against today's commits - > http://dl.dropbox.com/u/6901628/raw.patch The good news is, that this combo patch successfully compiles here. The bad new is, that today's 9 newly sent patches still fails here. I did regression test above them and 1of9 + 2of9 successfully compiles here, in other word first bad "commit" is 3of9. Adding config.log and output of ./configure (each as vanilla and patched for comparison). Regards, W. -- IHNED.cz je nový, přehlednější a rychlejší. Přesvědčte se na: www.ihned.cz

June 29, 2011

Re: Ge (Greg) van Geldorp

by Tom Wickline

Hello, Alexandre, is there the possibility we/you could have a release in Greg's memory? Cheers, Tom On Thu, Jun 30, 2011 at 12:47 AM, Erich Hoover <ehoover(a)mines.edu> wrote: > On Sat, Jun 11, 2011 at 3:47 PM, James McKenzie <jjmckenzie51(a)gmail.com>wrote: > >> ... It will take more than one person to fill Ge's shoes for providing >> the testbot system and for his actions to get our efforts recognized in the >> Virtual community. >> > > I think we should modify the testbot page to have a little memorial > message. If anything, I know that I can say that my contributions to the > animated cursor support are a direct result of the availability of the > testbot. Without the testbot I doubt I'd have ever figured out exactly how > GetCursorFrameInfo works. I know it'd been a while since this conversation > got started, but I've been a bit busy and I thought this idea was worth > mentioning. > > Erich Hoover > ehoover(a)mines.edu > > > > -- Wine is not a conclusion but a process...

June 29, 2011

Re: Ge (Greg) van Geldorp

by Erich Hoover

On Sat, Jun 11, 2011 at 3:47 PM, James McKenzie <jjmckenzie51(a)gmail.com>wrote: > ... It will take more than one person to fill Ge's shoes for providing the > testbot system and for his actions to get our efforts recognized in the > Virtual community. > I think we should modify the testbot page to have a little memorial message. If anything, I know that I can say that my contributions to the animated cursor support are a direct result of the availability of the testbot. Without the testbot I doubt I'd have ever figured out exactly how GetCursorFrameInfo works. I know it'd been a while since this conversation got started, but I've been a bit busy and I thought this idea was worth mentioning. Erich Hoover ehoover(a)mines.edu

June 29, 2011

Re: [1/2] include: Add declarations related to D3DXFLOAT16.

by Dylan Smith

On Wed, Jun 29, 2011 at 11:16 AM, Misha Koshelev <misha680(a)gmail.com> wrote: > Submitted by original author as requested by Alexandre. Necessary for > further patches by Dylan Smith to fix bug 25769. > Attached are the further patches he is referring to, which are based on his patch series.

June 29, 2011

Re: gcc 4.6 warning report

by Lauri Kenttä

On Wed, 29 Jun 2011 08:31:58 +0100, David Laight wrote: > On Tue, Jun 28, 2011 at 03:18:47PM -0700, Juan Lang wrote: >> >> This is a false positive. ?h_addr_list is declared as a char **, >> and >> >> technically it is, but gethostbyname only returns IPv4 addresses, >> i.e. >> >> ones that can fit in a DWORD. >> > >> > That doesn't sound like a problem that would give that warning. >> >> Why not? A cast of a pointer to a DWORD with 64-bit pointers would >> cause truncation, if it were indeed a pointer that were being cast. >> It isn't, even though it's declared that way. > > But 'char **h_addr_list;' is a pointer to an array of pointers > to address buffers (defined as char) - not a pointer to an array of > addresses. > IIRC the 'something' will be an IPv4 address - which might > be held as a 32 bit quantity rather that an array of char. > But nowhere should you cast the 32bit int (DWORD) to/from a pointer > type. David is right, the address is not stored as a pointer but as a DWORD in place of the chars. Like this: gethostbyname("winehq.org"): wrong: (DWORD) host->h_addr_list[i] = 0x00cbd1c8 = 200.209.203.0 right: *(DWORD*) host->h_addr_list[i] = 0x86192ed1 = 209.46.25.134 -- Lauri

June 29, 2011

Re: [1/2] oleaut32: COM Cleanup ICreateTypeLib2Imp (resend)

by Michael Stefaniuc

Hello Alistair, sorry that I missed the first time. And Alexandre should have marked it as PENDING (good idea but current implementation is rejected). Alistair Leslie-Hughes wrote: > Changelog: > oleaut32: COM Cleanup ICreateTypeLib2Imp > > > Best Regards > Alistair Leslie-Hughes > >From 4e5e70b84cc4a254e5e3bdfeb788282a20a3dd50 Mon Sep 17 00:00:00 2001 > From: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > Date: Mon, 27 Jun 2011 22:24:09 +1000 > Subject: [PATCH] COM Cleanup ICreateTypeLib2Imp > To: wine-patches <wine-patches(a)winehq.org> > > --- > dlls/oleaut32/typelib2.c | 75 ++++++++++++++++++++++++--------------------- > 1 files changed, 40 insertions(+), 35 deletions(-) > > diff --git a/dlls/oleaut32/typelib2.c b/dlls/oleaut32/typelib2.c > index e9c7613..5740ddd 100644 > --- a/dlls/oleaut32/typelib2.c > +++ b/dlls/oleaut32/typelib2.c > @@ -1476,7 +1481,7 @@ static HRESULT ctl2_find_typeinfo_from_offset( > > for (typeinfo = This->typeinfos; typeinfo; typeinfo = typeinfo->next_typeinfo) { > if (typeinfo->typeinfo == typeinfodata) { > - *ppTinfo = (ITypeInfo *)&typeinfo->lpVtblTypeInfo2; > + *ppTinfo = (ITypeInfo *)&typeinfo->ITypeInfo2_iface.lpVtbl; Please don't cast a vtable to an iface, cast the iface instead: + *ppTinfo = (ITypeInfo *)&typeinfo->ITypeInfo2_iface > ITypeInfo2_AddRef(*ppTinfo); > return S_OK; > } > @@ -1573,7 +1578,7 @@ static HRESULT WINAPI ICreateTypeInfo2_fnQueryInterface( > *ppvObject = This; > } else if (IsEqualIID(riid, &IID_ITypeInfo) || > IsEqualIID(riid, &IID_ITypeInfo2)) { > - *ppvObject = &This->lpVtblTypeInfo2; > + *ppvObject = &This->ITypeInfo2_iface.lpVtbl; No need to go here down to the vtable: + *ppvObject = &This->ITypeInfo2_iface It's the exact same thing but shorter. > } > > if(*ppvObject) > @@ -1697,7 +1702,7 @@ static HRESULT WINAPI ICreateTypeInfo2_fnSetTypeFlags(ICreateTypeInfo2 *iface, U > iter->next_typeinfo = This->dual; > } > } else > - iface = (ICreateTypeInfo2*)&This->dual->lpVtbl; > + iface = (ICreateTypeInfo2*)&This->dual->ICreateTypeInfo2_iface.lpVtbl; There's no need for a cast here as you already have the right thing: + iface = &This->dual->ICreateTypeInfo2_iface; > } > > if (uTypeFlags & (TYPEFLAG_FDISPATCHABLE|TYPEFLAG_FDUAL)) { You missed a few changes: @@ -3153,7 +3158,7 @@ { ICreateTypeInfo2Impl *This = impl_from_ITypeInfo2(iface); - return ICreateTypeInfo2_QueryInterface((ICreateTypeInfo2 *)This, riid, ppv); + return ICreateTypeInfo2_QueryInterface(&This->ICreateTypeInfo2_iface, riid, ppv); } There are more of those "(ICreateTypeInfo2 *)This" ==> "&This->ICreateTypeInfo2_iface" changes. Check for all (ICreateTypeInfo2 *), there should be none left. > @@ -3388,7 +3393,7 @@ static HRESULT WINAPI ITypeInfo2_fnGetRefTypeOfImplType( > } > > if(This->typekind == TKIND_DISPATCH) > - return ITypeInfo2_GetRefTypeOfImplType((ITypeInfo2*)&This->dual->lpVtblTypeInfo2, > + return ITypeInfo2_GetRefTypeOfImplType((ITypeInfo2*)&This->dual->ITypeInfo2_iface.lpVtbl, No need for the cast: + return ITypeInfo2_GetRefTypeOfImplType(&This->dual->ITypeInfo2_iface, > index, pRefType); > } > > @@ -3599,7 +3604,7 @@ static HRESULT WINAPI ITypeInfo2_fnGetRefTypeInfo( > return E_INVALIDARG; > > if(hRefType==-2 && This->dual) { > - *ppTInfo = (ITypeInfo*)&This->dual->lpVtblTypeInfo2; > + *ppTInfo = (ITypeInfo*)&This->dual->ITypeInfo2_iface.lpVtbl; Just cast the iface: + *ppTInfo = (ITypeInfo*)&This->dual->ITypeInfo2_iface; > ITypeInfo_AddRef(*ppTInfo); > return S_OK; > } > @@ -3635,7 +3640,7 @@ static HRESULT WINAPI ITypeInfo2_fnGetRefTypeInfo( > > for(iter=This->typelib->typeinfos; iter; iter=iter->next_typeinfo) { > if(This->typelib->typelib_typeinfo_offsets[i] == (hRefType&(~0x3))) { > - *ppTInfo = (ITypeInfo*)&iter->lpVtblTypeInfo2; > + *ppTInfo = (ITypeInfo*)&iter->ITypeInfo2_iface.lpVtbl; Same here: + *ppTInfo = (ITypeInfo*)&iter->ITypeInfo2_iface; > > ITypeLib_AddRef(*ppTInfo); > return S_OK; > @@ -4948,7 +4953,7 @@ static HRESULT WINAPI ITypeLib2_fnGetDocumentation( > if(!iter) > return TYPE_E_ELEMENTNOTFOUND; > > - return ITypeInfo_GetDocumentation((ITypeInfo*)&iter->lpVtblTypeInfo2, > + return ITypeInfo_GetDocumentation((ITypeInfo*)&iter->ITypeInfo2_iface.lpVtbl, And here: + return ITypeInfo_GetDocumentation((ITypeInfo*)&iter->ITypeInfo2_iface, > -1, pBstrName, pBstrDocString, pdwHelpContext, pBstrHelpFile); > } > thanks bye michael

June 29, 2011

Bad_Pool_Header

by Keith Muir

Hi, Been trying to run wine tests from http://test.winehq.org/data/ but every time I try this for about the last half dozen versions I get a blue screen and bad pool header any suggestions? I try to support the project by doing test runs and updating the appdb. Regards, Keith

June 29, 2011

Re: gcc 4.6 warning report

by David Laight

On Tue, Jun 28, 2011 at 03:18:47PM -0700, Juan Lang wrote: > >> This is a false positive. ?h_addr_list is declared as a char **, and > >> technically it is, but gethostbyname only returns IPv4 addresses, i.e. > >> ones that can fit in a DWORD. > > > > That doesn't sound like a problem that would give that warning. > > Why not? A cast of a pointer to a DWORD with 64-bit pointers would > cause truncation, if it were indeed a pointer that were being cast. > It isn't, even though it's declared that way. But 'char **h_addr_list;' is a pointer to an array of pointers to address buffers (defined as char) - not a pointer to an array of addresses. IIRC the 'something' will be an IPv4 address - which might be held as a 32 bit quantity rather that an array of char. But nowhere should you cast the 32bit int (DWORD) to/from a pointer type. David -- David Laight: david(a)l8s.co.uk

June 29, 2011

Re: wine bug 27600

by wylda＠volny.cz

> > Maybe gcc 4.4.5 is too old or i'm extremly dumb today :-/ > > > > Regards, > > W. > > > I'm not a WINE developer, just scratching my own > itch :) > > I have the same gcc version. Well, this might be a > legitimate issue, > another important thing would be to see the > ./configure output log. Thanks for interest :) That gives me hope, i won't be out of wine game ;) > I've merged the patch with the include lines > modified, so they would be > identical to the include files mostly used in the > other wineserver c files. > This is just a guess, I have no idea why it > doesn't work. There is also > today's commit, that changed include/winternl.h: > "ntdll: Encode the > function pointers in the vectored handler list", > but it's not related. > > The patch is rebased against today's commits - > http://dl.dropbox.com/u/6901628/raw.patch Nice to have all that 9+ changes in one box. So later today i will try to apply them on current fresh git tree and upload config.log if any trouble. If anything else comes to your mind in next 10hours don't hesitate to ask for, so i could report that too. Thanks, W. -- IHNED.cz je nový, přehlednější a rychlejší. Přesvědčte se na: www.ihned.cz

June 29, 2011

Re: wine bug 27600

by Vincas Miliūnas

On 06/29/2011 01:25 AM, wylda(a)volny.cz wrote: >> It fails on the #include "winternl.h" line and >> these are standard >> includes, you can try to replace >> >> [code] >> #include <stdarg.h> >> #include <stdio.h> >> [/code] >> >> code fragment with >> >> [code] >> #include "config.h" >> #include "wine/port.h" >> >> #include <assert.h> >> #include <stdarg.h> >> #include <stdio.h> >> [/code] >> >> maybe that will change something. > Unfortunately that's too generic for me (i can't handle code) :-( I > would need it in more detail way or a patch. But i'm not asking you > from that. I do not want to waste developers time ;) > > >> Others that have successfully built with the patch >> applied are WINE's >> testbot and two persons from >> http://bugs.winehq.org/show_bug.cgi?id=20395 > > Maybe gcc 4.4.5 is too old or i'm extremly dumb today :-/ > > Regards, > W. > > > I'm not a WINE developer, just scratching my own itch :) I have the same gcc version. Well, this might be a legitimate issue, another important thing would be to see the ./configure output log. I've merged the patch with the include lines modified, so they would be identical to the include files mostly used in the other wineserver c files. This is just a guess, I have no idea why it doesn't work. There is also today's commit, that changed include/winternl.h: "ntdll: Encode the function pointers in the vectored handler list", but it's not related. The patch is rebased against today's commits - http://dl.dropbox.com/u/6901628/raw.patch There are some paranormal stuff in wineserver, like in the first revision of this patch (I haven't tried since then), if I removed the user.h include (which is not used), some magical force was preventing from successfully copying lParam value in the peek_message function (it had the correct value from the source, but the target was reset back to some constant) for each WM_INPUT message I posted, while other messages where working just fine.

June 28, 2011

Re: wine bug 27600

by wylda＠volny.cz

> It fails on the #include "winternl.h" line and > these are standard > includes, you can try to replace > > [code] > #include <stdarg.h> > #include <stdio.h> > [/code] > > code fragment with > > [code] > #include "config.h" > #include "wine/port.h" > > #include <assert.h> > #include <stdarg.h> > #include <stdio.h> > [/code] > > maybe that will change something. Unfortunately that's too generic for me (i can't handle code) :-( I would need it in more detail way or a patch. But i'm not asking you from that. I do not want to waste developers time ;) > Others that have successfully built with the patch > applied are WINE's > testbot and two persons from > http://bugs.winehq.org/show_bug.cgi?id=20395 Maybe gcc 4.4.5 is too old or i'm extremly dumb today :-/ Regards, W. -- IHNED.cz je nový, přehlednější a rychlejší. Přesvědčte se na: www.ihned.cz

June 28, 2011

Re: gcc 4.6 warning report

by Juan Lang

>> This is a false positive. h_addr_list is declared as a char **, and >> technically it is, but gethostbyname only returns IPv4 addresses, i.e. >> ones that can fit in a DWORD. > > That doesn't sound like a problem that would give that warning. Why not? A cast of a pointer to a DWORD with 64-bit pointers would cause truncation, if it were indeed a pointer that were being cast. It isn't, even though it's declared that way. --Juan

June 28, 2011

Re: wine bug 27600

by Vincas Miliūnas

On 06/29/2011 12:28 AM, wylda(a)volny.cz wrote: >> Looks like there is some external interference, >> try compiling in a clean >> bash environment; some googling suggests that >> LIBRARY_PATH variable >> should be unset - >> https://bbs.archlinux.org/viewtopic.php?id=30418 >> First be sure it can compile the original master >> branch without issues. > > Still fails here :-/ > > * succesfully compiled vanilla wine-1.3.23-50-g2497a91 > * make distclean > * applied all nine patches > * unset LIBRARY_PATH > * ./tools/make_requests //3 files updated > * ./configure > * make -j 16 > > Debian 32 squeeze, gcc v4.4.5, no CFLAGS override. > > > It fails on the #include "winternl.h" line and these are standard includes, you can try to replace [code] #include <stdarg.h> #include <stdio.h> [/code] code fragment with [code] #include "config.h" #include "wine/port.h" #include <assert.h> #include <stdarg.h> #include <stdio.h> [/code] maybe that will change something. Others that have successfully built with the patch applied are WINE's testbot and two persons from http://bugs.winehq.org/show_bug.cgi?id=20395

June 28, 2011

Re: gcc 4.6 warning report

by David Laight

On Tue, Jun 28, 2011 at 12:51:02PM -0700, Juan Lang wrote: > ../../../dlls/netapi32/nbt.c:580:30: warning: cast from pointer to > integer of different size [-Wpointer-to-int-cast] > > This is a false positive. h_addr_list is declared as a char **, and > technically it is, but gethostbyname only returns IPv4 addresses, i.e. > ones that can fit in a DWORD. That doesn't sound like a problem that would give that warning. David -- David Laight: david(a)l8s.co.uk

June 28, 2011

Re: wine bug 27600

by wylda＠volny.cz

> Looks like there is some external interference, > try compiling in a clean > bash environment; some googling suggests that > LIBRARY_PATH variable > should be unset - > https://bbs.archlinux.org/viewtopic.php?id=30418 > First be sure it can compile the original master > branch without issues. Still fails here :-/ * succesfully compiled vanilla wine-1.3.23-50-g2497a91 * make distclean * applied all nine patches * unset LIBRARY_PATH * ./tools/make_requests //3 files updated * ./configure * make -j 16 Debian 32 squeeze, gcc v4.4.5, no CFLAGS override. -- IHNED.cz je nový, přehlednější a rychlejší. Přesvědčte se na: www.ihned.cz

June 28, 2011

Re: wine bug 27600

by Vincas Miliūnas

On 06/29/2011 12:10 AM, wylda(a)volny.cz wrote: > So i another try: > * rm -rf * in my git tree. > * git checkout -f 2497a91f6b1326988dd5ea56dc4052cbcc2e521d > * applied all nine patches > * ./tools/make_requests > * configure + make with -O2 and got again: > >> In file included from raw_input.c:28: >> ../include/winternl.h:2359: error: expected >> declaration specifiers >> or ‘...’ before ‘va_list’ >> ../include/winternl.h:2529: error: expected >> declaration specifiers >> or ‘...’ before ‘va_list’ >> ../include/winternl.h:2530: error: expected >> declaration specifiers >> or ‘...’ before ‘va_list’ >> > > > Looks like there is some external interference, try compiling in a clean bash environment; some googling suggests that LIBRARY_PATH variable should be unset - https://bbs.archlinux.org/viewtopic.php?id=30418 First be sure it can compile the original master branch without issues. Compilation with the patch after make distclean works for me.

June 28, 2011

Re: wine bug 27600

by wylda＠volny.cz

So i another try: * rm -rf * in my git tree. * git checkout -f 2497a91f6b1326988dd5ea56dc4052cbcc2e521d * applied all nine patches * ./tools/make_requests * configure + make with -O2 and got again: > > In file included from raw_input.c:28: > ../include/winternl.h:2359: error: expected > declaration specifiers > or ‘...’ before ‘va_list’ > ../include/winternl.h:2529: error: expected > declaration specifiers > or ‘...’ before ‘va_list’ > ../include/winternl.h:2530: error: expected > declaration specifiers > or ‘...’ before ‘va_list’ > -- IHNED.cz je nový, přehlednější a rychlejší. Přesvědčte se na: www.ihned.cz

June 28, 2011