August 2012 - Wine-Devel - list.winehq.org

Re: wshom.ocx/tests: Use proper method macro

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=21198 Your paranoid android. === WINEBUILD (build) === Can't determine base name

Aug. 24, 2012

Re: [2/16] po: Update Russian translation

by Nikolay Sivov

On 8/24/2012 10:14, Oleg Yarigin wrote: > #: comctl32.rc:88 > msgid "&Add ->" > -msgstr "&Добавить ->" > +msgstr "&Добавить →" > #: comctl32.rc:89 > msgid "<- &Remove" > -msgstr "<- &Удалить" > +msgstr "← &Удалить" I don't think so. > #: comdlg32.rc:157 comdlg32.rc:179 > msgid "&Directories:" > -msgstr "&Каталоги:" > +msgstr "&Папки:" New translation is traditionally used for 'folders' mostly. I agree there's a mess in directory/folder/catalogue here though. > #: comdlg32.rc:223 > msgid "[none]" > -msgstr "[нет]" > +msgstr "(нет)" Why? > #: comdlg32.rc:282 > msgid "&Red:" > -msgstr "Крас&н:" > +msgstr "Крас&ный:" The reason was it doesn't fit a dialog template otherwise, did you check that? > #: comdlg32.rc:52 > msgid "Unreadable Entry" > -msgstr "Нечитаемый элемент" > +msgstr "Нераспознаваемый элемент" You translated 'unrecognised' instead of 'unreadable'. > #: comdlg32.rc:65 > msgid "Cannot find the printer." > -msgstr "Не удалось найти принтер." > +msgstr "Принтер не найден." However I like this kind of changes, it's a good example of keeping it short while it means the same. > #: comdlg32.rc:91 > msgid "Output tray is full; " > -msgstr "Лоток переполнен бумагой; " > +msgstr "Лоток для бумаги переполнен; " Could be "Лоток полон;" ... I can't comment on the rest of this series but there's a lot to fix already.

Aug. 24, 2012

Re: [1/16] po: Update Russian translation

by Nikolay Sivov

On 8/24/2012 10:13, Oleg Yarigin wrote: > > > "To install a new program from a floppy disk, CD-ROM drive, or your hard " > "drive, click Install." > msgstr "" > -"Чтобы установить программу с CD-ROM, дискеты или жёсткого диска, нажмите " > -"Установить." > +"Для установки программы с компакт- или жёсткого диска нажмите «Установить»." You only need to fix quotation marks in original string, the variant you proposed doesn't say what English string is saying. > #: appwiz.rc:62 > -msgid "" > -"The following software can be automatically removed. To remove a program or " > -"to modify its installed components, select it from the list and click Modify/" > -"Remove." > -msgstr "" > -"Перечисленные программы можно автоматически удалить. Чтобы удалить программу " > -"или изменить состав установленных компонентов, выберите её в списке и " > +msgid "The following software can be automatically removed. To remove a " > +"program or to modify its installed components, select it from the list and " > +"click Modify/Remove." > +msgstr "Перечисленные программы могут быть удалены. Для удаления " > +"или изменения состава установленных компонентов, выберите их в списке и " > "нажмите кнопку Изменить/Удалить." Again, don't alter original meaning, no reason to remove 'automatically' here. > #: appwiz.rc:76 > msgid "The following information can be used to get technical support for %s:" > -msgstr "" > -"Указанная информация может быть использована для получения технической " > +msgstr "Указанная информация может быть использована для получения технической " > "поддержки приложения %s:" Nothing changed here. > #: appwiz.rc:35 shell32.rc:141 shell32.rc:238 regedit.rc:122 winefile.rc:104 > msgid "Name" > -msgstr "Имя" > +msgstr "Название" That's questionable. If you really want to change that it will need to depend on context I guess. > #: avifil32.rc:33 > msgid "Wine AVI-default-filehandler" > -msgstr "Обработчик по умолчанию avi-файлов в Wine" > +msgstr "Обработчик avi-файлов по умолчанию в Wine" This alters a meaning a bit, now what you did means that there're some default avi-files in Wine.

Aug. 24, 2012

Re: configure --with-osmesa fails to link

by Alexandre Julliard

Peter Urbanec <winehq.org(a)urbanec.net> writes: > Any suggestions as to how this could be fixed? My autoconf skills are > no match for this problem :-( libOSMesa should be built without shared-glapi, we can't use it otherwise. -- Alexandre Julliard julliard(a)winehq.org

Aug. 24, 2012

Re: oleaut32: VaraintChangeType to support VT_BSTR to VT_UI2|VT_ARRAY

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=21195 Your paranoid android. === WNT4WSSP6 (32 bit safearray) === safearray.c:564: Test failed: CTE VT_BSTR -> VT_UI1|VT_ARRAY failed with 80020008 safearray.c:565: Test failed: CTE BSTR -> VT_UI1|VT_ARRAY did not return VT_UI1|VT_ARRAY, but 8.v === WXPPROSP3 (32 bit safearray) === safearray.c:564: Test failed: CTE VT_BSTR -> VT_UI1|VT_ARRAY failed with 80020008 safearray.c:565: Test failed: CTE BSTR -> VT_UI1|VT_ARRAY did not return VT_UI1|VT_ARRAY, but 8.v === WVISTAADM (32 bit safearray) === safearray.c:564: Test failed: CTE VT_BSTR -> VT_UI1|VT_ARRAY failed with 80020008 safearray.c:565: Test failed: CTE BSTR -> VT_UI1|VT_ARRAY did not return VT_UI1|VT_ARRAY, but 8.v === W2K8SE (32 bit safearray) === safearray.c:564: Test failed: CTE VT_BSTR -> VT_UI1|VT_ARRAY failed with 80020008 safearray.c:565: Test failed: CTE BSTR -> VT_UI1|VT_ARRAY did not return VT_UI1|VT_ARRAY, but 8.v === W7PRO (32 bit safearray) === safearray.c:564: Test failed: CTE VT_BSTR -> VT_UI1|VT_ARRAY failed with 80020008 safearray.c:565: Test failed: CTE BSTR -> VT_UI1|VT_ARRAY did not return VT_UI1|VT_ARRAY, but 8.v === W7PROX64 (32 bit safearray) === safearray.c:564: Test failed: CTE VT_BSTR -> VT_UI1|VT_ARRAY failed with 80020008 safearray.c:565: Test failed: CTE BSTR -> VT_UI1|VT_ARRAY did not return VT_UI1|VT_ARRAY, but 8.v === TEST64_W7SP1 (32 bit safearray) === safearray.c:564: Test failed: CTE VT_BSTR -> VT_UI1|VT_ARRAY failed with 80020008 safearray.c:565: Test failed: CTE BSTR -> VT_UI1|VT_ARRAY did not return VT_UI1|VT_ARRAY, but 8.v === W7PROX64 (64 bit safearray) === safearray.c:564: Test failed: CTE VT_BSTR -> VT_UI1|VT_ARRAY failed with 80020008 safearray.c:565: Test failed: CTE BSTR -> VT_UI1|VT_ARRAY did not return VT_UI1|VT_ARRAY, but 8.v === TEST64_W7SP1 (64 bit safearray) === safearray.c:564: Test failed: CTE VT_BSTR -> VT_UI1|VT_ARRAY failed with 80020008 safearray.c:565: Test failed: CTE BSTR -> VT_UI1|VT_ARRAY did not return VT_UI1|VT_ARRAY, but 8.v

Aug. 24, 2012

Re: configure --with-osmesa fails to link

by Henri Verbeet

That's a Mesa bug (https://bugs.freedesktop.org/show_bug.cgi?id=47824) It might be fixed in current Mesa git, but you should be able to avoid it by disabling shared-glapi either way.

Aug. 24, 2012

Re: oleaut32: VaraintChangeType to support VT_BSTR to VT_UI2|VT_ARRAY

by Dmitry Timoshkov

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Changelog: > oleaut32: VaraintChangeType to support VT_BSTR to VT_UI2|VT_ARRAY Please resend the test separately, your fix conflicts with the patch sent by Roman Dadkov. -- Dmitry.

Aug. 24, 2012

Re: [1/16] po: Update Russian translation

by Dmitry Timoshkov

These new translations look at least questionable to say the least. -- Dmitry.

Aug. 24, 2012

Re: dssenh/tests: Added key exchange tests for the DSSENH cryptographic service provider

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=21186 Your paranoid android. === TEST64_W7SP1 (32 bit dssenh) === dssenh.c:1144: Test failed: Expected ERROR_INVALID_PARAMETER, got 80090008 dssenh.c:1144: Test failed: Expected ERROR_INVALID_PARAMETER, got 80090008 dssenh.c:1144: Test failed: Expected ERROR_INVALID_PARAMETER, got 80090008

Aug. 23, 2012

configure --with-osmesa fails to link

by Peter Urbanec

I just turned on --with-osmesa and configure fails for me: > checking for -lOSMesa... not found > configure: error: libOSMesa development files not found (or too old), > OpenGL rendering in bitmaps won't be supported. > This is an error since --with-osmesa was requested config.log output would suggest that perhaps the test is being treated as C code, but libOSMesa needs to link with C++ libs. > configure:9067: checking for -lOSMesa > configure:9092: gcc -o conftest -g3 -feliminate-unused-debug-symbols > -O0 -mtune=core2 conftest.c -lOSMesa -lSM -lICE -lXext -lX11 > -lm >&5 > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `operator delete[](void*)' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `operator new(unsigned long)' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_get_proc_address' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `operator delete(void*)' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_get_dispatch_table_size' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `operator new[](unsigned long)' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `__cxa_pure_virtual' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `__gxx_personality_v0' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_get_context' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `vtable for __cxxabiv1::__class_type_info' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_add_dispatch' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_check_multithread' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_tls_Context' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_set_context' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `vtable for __cxxabiv1::__si_class_type_info' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_set_dispatch' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_tls_Dispatch' > collect2: ld returned 1 exit status This is on Gentoo x64 with: media-libs/mesa-8.1_rc1_pre20120814 (classic egl g3dvl gallium llvm nptl osmesa shared-glapi vdpau xvmc -bindist -d3d -debug -gbm -gles1 -gles2 -kernel_FreeBSD -openvg -pax_kernel -pic -r600-llvm-compiler -selinux -video_cards_i915 -video_cards_i965 -video_cards_intel -video_cards_nouveau -video_cards_r100 -video_cards_r200 -video_cards_r300 -video_cards_r600 -video_cards_radeon -video_cards_radeonsi -video_cards_vmware -wayland -xa -xorg) sys-devel/gcc-4.6.3 (cxx fortran graphite mudflap multilib nls nptl openmp -altivec -bootstrap -build -doc -fixed-point -gcj -go -gtk -hardened -libssp -multislot -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla) Any suggestions as to how this could be fixed? My autoconf skills are no match for this problem :-( Thanks.

Aug. 23, 2012

Re: Have there been any problems with Wine on GCC 4.7?

by Austin English

On Thu, Aug 23, 2012 at 12:56 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > >> -g was already the default. Most packagers (to my knowledge) provide a >> separate debug package, which isn't installed by default. >> > i'm not especially speaking of packagers, but folks who compile wine > themselves with something like: > ./configure CFLAGS=-O2 > and your patch forces -gdwarf2 (whatever -g is requested or not in CFLAGS) > hence providing debug info when the user didn't ask for it > > A+ AJ's taken care of it: http://source.winehq.org/git/wine.git/commitdiff/ce48e2c8ab4537fb57e4416d03… -- -Austin

Aug. 23, 2012

Re: d3dx9: ID3DXConstantTable

by Rico Schüller

On 23.08.2012 15:43, Józef Kucia wrote: > I would prefer you to clean it up submit it. I hope it gets committed > this time. Ok, I'll try to clean them and send them. I will do it the safe way and compare each handle with all handles we have. If it is slow, we could easily move by using the highest bit for comparison against the D3DXHANDLE. We just have to take care that an easy switch is possible. Thanks for the input. Rico

Aug. 23, 2012

Re: Have there been any problems with Wine on GCC 4.7?

by Eric Pouech

> -g was already the default. Most packagers (to my knowledge) provide a > separate debug package, which isn't installed by default. > i'm not especially speaking of packagers, but folks who compile wine themselves with something like: ./configure CFLAGS=-O2 and your patch forces -gdwarf2 (whatever -g is requested or not in CFLAGS) hence providing debug info when the user didn't ask for it A+

Aug. 23, 2012

Re: hhctrl.ocx: Make MergeChmProperties() static.

by Erich E. Hoover

I'm going to need MergeChmProperties() for HH_SET_WIN_TYPE. I've just been really busy lately and have not had a chance to cleanup my patches yet (from discussions with Jacek it looks like we need to redo storing HH_WINTYPE data a little bit). Erich

Aug. 23, 2012

Re: [PATCH 1/3] dinput: Disable linuxinput or linux joysticks based on registry key (try 2)

by Alexandre Julliard

Lucas Zawacki <lfzawacki(a)gmail.com> writes: >> That's better, thanks. You probably want to put them under a subkey >> though, to avoid mixing up the joystick names with the other >> configuration values. > > No problem. If I put them under a key "Disabled" I think it's ok to > not ask for a value, just a key with the joystick name right? It's better to use something like "Joysticks" and explicit values, we may want more per-joystick options at some point. -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2012

Re: [PATCH 1/3] dinput: Disable linuxinput or linux joysticks based on registry key (try 2)

by Lucas Zawacki

> That's better, thanks. You probably want to put them under a subkey > though, to avoid mixing up the joystick names with the other > configuration values. No problem. If I put them under a key "Disabled" I think it's ok to not ask for a value, just a key with the joystick name right?

Aug. 23, 2012

Re: [PATCH 2/3] joy.cpl: Using joystick name suffixed with driver when in Linux (try 2)

by Lucas Zawacki

> I think dinput should be appending that to the returned name, joy.cpl > shouldn't have to know about the specific naming scheme of the driver. Do you mean change the reported name directly at device creation time? I could do that and I guess that would be mostly harmless, do other people working on dinput have something against this?

Aug. 23, 2012

Re: d3dx9: ID3DXConstantTable

by Alexandre Julliard

Rico Schüller <kgbricola(a)web.de> writes: > So in cases, where the exe is linked with LARGEADDRESSAWARE, d3dx9 > would have to be used with D3DXCONSTTABLE_LARGEADDRESSAWARE. Yes, but in practice apps don't do that. Eve Online was reportedly one of the offenders, there are certainly others. -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2012

Re: d3dx9: ID3DXConstantTable

by Józef Kucia

On Wed, Aug 22, 2012 at 2:45 PM, Rico Schüller <kgbricola(a)web.de> wrote: > Well, I just had a closer look again. My speed test triggers a problem, so > it's not really comparable. But it looks like native only allocates > handles, if it really needs them. So I'm not sure we like to go the same > approach or if it is fine allocating them all like I've done that. I fixed > the test and native speed advantage was blown away. Although, if that's > fine with your opinion, you could reuse the code or I could clean it up a > bit and send it. I haven't send it and improved it, yet, because the > problem with solution 1. or 2. isn't solved for me. I'm a little bit > against version 1., because I think speed might be an issue and no one had > a technical argument against 2. I don't think a extra handle list for > handles with "small" values is the way to got, because it may also hit the > values where strings could be in memory. The extra handle list would be 3., > but I think it needs a lot more memory for just adding a "layer" for > checking the handles. Thus 2. is a lot better than 3. (which I haven't > explained in detail). > I would prefer you to clean it up submit it. I hope it gets committed this time. > So in cases, where the exe is linked with LARGEADDRESSAWARE, d3dx9 would > have to be used with D3DXCONSTTABLE_LARGEADDRESSAWARE. That way it's the > same for os with 32bit and 64bit. The only problem I see, nowhere is said, > that the 2gb will always be the lowest 2gb. But my tests showed, that I > always get the lower 31bit of addresses in my test runs when allocating > memory. Thus I'm very unlucky by not getting a higher address or this might > be the way it works on windows. Has anyone a technical argument against > this solution? > It seems fine to me. A program compiled without *LARGEADDRESSAWARE* should get all the memory allocated below the 2 GB limit (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa384271%28v=vs.85%… ). -- Józef Kucia

Aug. 23, 2012

Re: Testing Gdi+

by Dmitry Timoshkov

Stepa Nick <hired777(a)gmail.com> wrote: > I`m new in WINE development. I have some tests cases, that works > incorrect in current version of WINE and I want to fix this mistakes. > So, I`m interesting are there some testing systems that compares > bitmap(for example)? I look thru WINE tests, > http://www.winehq.org/docs/winedev-guide/testing and had found only > tests, that compare some variables to constant. I think, that WINE > needs graphics test. Comparing resulting image/bitmap output of gdiplus between Wine and Windows is not useful, because they will always differ, even in small details. Better spend your time comparing numeric values, have a look at existing gdiplus tests how it's done there. If you can't for some reason figire it out just open a bug report and attach your source code there with detailed description of the problem(s). -- Dmitry.

Aug. 23, 2012

Testing Gdi+

by Stepa Nick

Hi! I`m new in WINE development. I have some tests cases, that works incorrect in current version of WINE and I want to fix this mistakes. So, I`m interesting are there some testing systems that compares bitmap(for example)? I look thru WINE tests, http://www.winehq.org/docs/winedev-guide/testing and had found only tests, that compare some variables to constant. I think, that WINE needs graphics test. Thanks.

Aug. 23, 2012

Re: [PATCH 2/3] joy.cpl: Using joystick name suffixed with driver when in Linux (try 2)

by Alexandre Julliard

Lucas Zawacki <lfzawacki(a)gmail.com> writes: > @@ -57,6 +57,34 @@ BOOL WINAPI DllMain(HINSTANCE hdll, DWORD reason, LPVOID reserved) > return TRUE; > } > > +static void get_joystick_name(struct Joystick *joy) > +{ > + /* Base product guids as Wine defines them in DirectInput */ > + /* 9e573ed9-7734-11d2-8d4a-23903fb6bdf7 */ > + static const GUID linux_guid = { 0x9e573ed9, 0x7734, 0x11d2, {0x8d, 0x4a, 0x23, 0x90, 0x3f, 0xb6, 0xbd, 0xf7} }; > + /* 9e573eda-7734-11d2-8d4a-23903fb6bdf7 */ > + static const GUID linuxinput_guid = { 0x9e573eda, 0x7734, 0x11d2, {0x8d, 0x4a, 0x23, 0x90, 0x3f, 0xb6, 0xbd, 0xf7} }; > + static REFGUID wine_guids[] = { &linux_guid, &linuxinput_guid }; > + static const WCHAR wine_device_names[2][9] = { {'(','j','s',')','\0'}, {'(','e','v','e','n','t',')','\0'} }; I think dinput should be appending that to the returned name, joy.cpl shouldn't have to know about the specific naming scheme of the driver. -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2012

Re: [PATCH 1/3] dinput: Disable linuxinput or linux joysticks based on registry key (try 2)

by Alexandre Julliard

Lucas Zawacki <lfzawacki(a)gmail.com> writes: > From: Lucas Fialho Zawacki <lfzawacki(a)gmail.com> > > In the form of "controllername(drivername)"="disabled" key > > Examples: > Disable the linux js driver for "Usb Controller" device > "Usb Controller(js)"="disabled" > > Disable the linux js and event drivers for "Other Controller" device > "OtherController(event)"="disabled" > "OtherController(js)"="disabled" That's better, thanks. You probably want to put them under a subkey though, to avoid mixing up the joystick names with the other configuration values. -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2012

Re: wine/server: removed obsolete one-iteration loop from request forming macro (try 2)

by Marcus Meissner

On Thu, Aug 23, 2012 at 11:14:23AM +0400, Oleg Yarigin wrote: > An original message was sent with wrong author`s name by mistake, so > I resend this patch with hope it was the only reason to reject it. It was not the only reason. A single loop is a common pattern in C to allow safe encapsulation and handling of blocks, or doing "break;"/"continue;" style things. One thing that it allows here in Wine is that the variable definitions are at the begin of a { } block and not in the middle of the code to allow old C standard builds to work still. There is no "break;" usage, although I spotted 1 "goto done;" which could be just a break; ;) The compiler will optimize everything of those loops away, so this change also brings no performance improvement. Ciao, Marcus > --- > include/wine/server.h | 22 +++++++++------------- > 1 file changed, 9 insertions(+), 13 deletions(-) > > diff --git a/include/wine/server.h b/include/wine/server.h > index d573d1f..dcbc7fa 100644 > --- a/include/wine/server.h > +++ b/include/wine/server.h > @@ -124,19 +124,15 @@ static inline void *wine_server_get_ptr( client_ptr_t ptr ) > /* macros for server requests */ > > #define SERVER_START_REQ(type) \ > - do { \ > - struct __server_request_info __req; \ > - struct type##_request * const req = &__req.u.req.type##_request; \ > - const struct type##_reply * const reply = &__req.u.reply.type##_reply; \ > - memset( &__req.u.req, 0, sizeof(__req.u.req) ); \ > - __req.u.req.request_header.req = REQ_##type; \ > - __req.data_count = 0; \ > - (void)reply; \ > - do > - > -#define SERVER_END_REQ \ > - while(0); \ > - } while(0) > + struct __server_request_info __req; \ > + struct type##_request * const req = &__req.u.req.type##_request; \ > + const struct type##_reply * const reply = &__req.u.reply.type##_reply; \ > + memset( &__req.u.req, 0, sizeof(__req.u.req) ); \ > + __req.u.req.request_header.req = REQ_##type; \ > + __req.data_count = 0; \ > + (void)reply; > + > +#define SERVER_END_REQ > > > #endif /* __WINE_WINE_SERVER_H */ > -- 1.7.9.5 > > -- Open Linux Security Engineer Position at SUSE: http://bit.ly/Li4RbS

Aug. 23, 2012

Re: Have there been any problems with Wine on GCC 4.7?

by Scott Ritchie

On 8/21/12 12:17 PM, Austin English wrote: > On Mon, Aug 20, 2012 at 11:55 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: >> >>> >>> >>> http://source.winehq.org/git/wine.git/commitdiff/3f1dbaf3df0ae8ec2f0e86191e… >>> >>> -- >>> -Austin >> >> >> the trouble with this patch is that it enables debug info whatever the >> default configuration is... >> A+ >> >> -- >> Eric Pouech > > -g was already the default. Most packagers (to my knowledge) provide a > separate debug package, which isn't installed by default. > Correct, the symbols get split out (in Ubuntu Packaging this is handled mostly automatically after just giving the name of the debug package) -Scott Ritchie

Aug. 22, 2012