wine-devel

wine-devel@winehq.org

4 participants
84472 discussions

-gstabs and '#warning "8 as alignment is not supported"'
by Greg Turner 27 Sep '02

27 Sep '02

OK, I did this: Index: configure =================================================================== RCS file: /home/wine/wine/configure,v retrieving revision 1.341 diff -u -r1.341 configure --- configure 25 Sep 2002 03:29:55 -0000 1.341 +++ configure 27 Sep 2002 15:20:40 -0000 @@ -1998,7 +1998,7 @@ CFLAGS=$ac_save_CFLAGS elif test $ac_cv_prog_cc_g = yes; then if test "$GCC" = yes; then - CFLAGS="-g -O2" + CFLAGS="-gstabs -O2" else CFLAGS="-g" fi and sure enough, debug symbols loaded for me. The only remaining annoyance: winedbg doesn't automagically find the sources like gdb. Presumably, I can fix this by issuing "dir" commands to winedbg. So I'm happy (although it'd be nice to not have to issue those "dir" commands). Thanks! Can anyone think of a reason not to submit this as a patch? I tried -gstabs in gcc 2.96 (the only other gcc readily available to me) and it was happy, so presumably its pretty portable, and it looks like the configure change above would only apply to gcc, which seems like precisely the right thing to me. Now one other question for y'all wine gurus out there: I was looking for the alignment issue I mentioned before, and it turns out not to be an "-malign=" problem like I was suspecting. Instead, I was seeing "8 as alignment is not supported" warnings from include/pshpack8.h: # if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__SUNPRO_CC) || defined(_MSC_VER) # pragma pack(8) # warning "8 as alignment is not supported" # elif !defined(RC_INVOKED) # error "Adjusting the alignment is not supported with this compiler" # endif I don't understand, if the alignment isn't supported, why the #pragma pack(8) is there...? Anyhow, since it looks like everybody using gcc gets the same warning, it's probably not a gcc3.2 bug... but I was wondering if anyone could clarify what's going on, and whether this indicates a problem in crypt32.dll.so (the affected wine dll). Thanks for your patience and help, -gmt -- "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993

1 0

Re: winemaker: wineapploader changes
by Alexandre Julliard 27 Sep '02

27 Sep '02

Francois Gouget <fgouget(a)codeweavers.com> writes: > However, looking for wine in bindir does not make sense: > * I don't install the Winelib applications I compile using Winelib. So > * I leave prefix to the default value: /usr/local > > * I always build my application using a Wine source tree. This means > * that there is strictly nothing of interest in /usr/local/bin. > > * configure.ac goes to great length to figure out where wrc, winebuild > * and *wine* are located. So at the end of configure.ac we know very > * well what the path to wine is. It's '$WINE'. There seems to be some confusion here. We have two very different problems: one is how to make things work on the build machine, and one is how to make things work when installed. configure can only detect where things are on the build machine, but in general that's not the right paths to put in the installed binaries. The installed stuff goes in $(prefix), and I think it makes sense to expect that Wine itself will be installed there too. Note that in Wine wineapploader is only used for make install; running from inside the tree is a different problem and is done by a different script. I think winemaker should do the same thing. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winedbg is not finding debug symbols, anybody know what I'm doing wrong?
by Greg Turner 27 Sep '02

27 Sep '02

Eric POUECH wrote... > but I assume you double checked that more likely, aren't you using gcc 3.2 > by any chance ? if so, you need to force ELF symbol emission, not > Dwarf II which became default in 3.2 Bingo. Guilty as charged. Thank you SO MUCH for this, I should have figured gcc3.2 was the culprit, that thing is feisty! I'll take a look at whether I can find a generic solution to this and post a patch. Now that you mention it, I think gcc3.2 has some other interesting warnings, something about some alignment thingys not supported anymore (probably I just change "-m$X" to "-f$X" to fix), I'll see about those too, could well be important... -gmt -- "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993

2 1

Re: Unimplemented function... Cause of exception?
by Andriy Palamarchuk 27 Sep '02

27 Sep '02

--- John Coppens <jcoppens(a)usa.net> wrote: > Hello. > > I'm trying to run WinPLACE with the last wine > package. The composition part > works, but the compiler doesn't. I get: > > fixme:int:DOSVM_Int10Handler Get Font Information - > Not Supported (BH: 0x0) > wine: Unhandled exception, starting debugger... The fixme message may or may not have the relation to the exception. What does debugger say about the exception? Run "bt" (backtrace) command in the debugger window and report what you found. Also you can get more information about the cause of the crash from relay trace. See: http://www.winehq.org/docs/wine-devel/dbg-param.shtml http://www.winehq.org/fom-meta/cache/266.html Andriy Boston, MA, USA As an employee of an oil company, let me assure you that nothing, and I mean NOTHING scares a big company more than a noisy, smelly, obnoxious, disaffected pressure group. Now go away and chain yourself to someone important's front door. TheRegister. Unknown __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com

2 1

Where is the specfile documented nowadays?
by Bill Medland 27 Sep '02

27 Sep '02

I've just come back to WineLib after a long time and discovered that things have changed a bit. (As a result my code finds the builtin dll but complains that it loaded the so but the dll is not found; I guess it hasn't been named or something) I guess we need to update the winelib documentation and the "binary dlls" part. As I understand it the spec file format has changed significantly over the past year and half the contents go somewhere else. In particular all that seems to go in the spec file nowadays is the entrypoint and the actual functions. Can someone point me at the current documentation or is there none. Bill

4 8

dlls/xxx/xxx_main.c
by Dimitrie O. Paun 27 Sep '02

27 Sep '02

Can we please rename all these dlls/xxx/xxx_main.c to dlls/xxx/xxx.c It should be possible now, right? Should I send a patch in? -- Dimi.

2 1

[Controversial] Developper only CVS sandbox
by Lionel Ulmer 26 Sep '02

26 Sep '02

Hi all, As Dimi is not the only one that can start flames on wine-devel, let's start a new one :-) When I see the work that is starting to go on on D3D8 or even on my old D3D code, I think that it would be nice if there was some CVS 'sandbox' where Wine developper could interact on shared code without going the Alexandre round-trip. This would be much less painful than sending patches back and forth between developpers. This sandbox would be closed (ie it would be a developper only Wine tree) to NOT start another Wine fork and all development on this sandbox would be merged back in Wine when they are ready (and then would still go the Alexandre way of course). Now, what does the Wine community think about this ? If people agree, what would be the best way to handle this ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

5 5

winedbg is not finding debug symbols, anybody know what I'm doing wrong?
by Greg Turner 26 Sep '02

26 Sep '02

Whenever I run winedbg (or when wine runs it in response to an exception), it fails to find debug symbols. Looking at disassembled code is making my brain numb. I "export STRIP=false" before configure to ensure that the Makefile doesn't strip anything, and gdb finds everything just fine. So what am I doing wrong? The doc says winedbg should know all about this, and I see examples of people's winedbg runs on the internet where winedbg is automagically loading tons of symbols for them (I only seem to get libntdll.dll.so working). Here's a typical run: wine: Unhandled exception, starting debugger... WineDbg starting on pid 8078e48 No debug information in ELF 'wine' (0x00000000) Breakpoint 1 at 0x4000b0a0 Loaded debug information from ELF '/usr/local/lib/libntdll.dll.so' (0x4002e000) No debug information in ELF '/usr/local/lib/libwine.so' (0x40161000) No debug information in ELF '/usr/local/lib/libwine_unicode.so' (0x4017a000) No debug information in ELF '/lib/libm.so.6' (0x40244000) No debug information in ELF '/lib/libc.so.6' (0x40268000) No debug information in ELF '/lib/libdl.so.2' (0x403a3000) No debug information in ELF '/lib/ld-linux.so.2' (0x40000000) No debug information in ELF '/usr/local/lib/wine/kernel32.dll.so' (0x406e3000) No debug information in ELF '/usr/local/lib/wine/user32.dll.so' (0x407a1000) No debug information in ELF '/usr/local/lib/wine/gdi32.dll.so' (0x40909000) . . . Wine-dbg>step Single stepping until exit from function, which has no line number information. First chance exception: c0000025 in 32-bit code (0x4010b7ee). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000 EIP:4010b7ee ESP:406caa70 EBP:406cab10 EFLAGS:00000246( - 00 I Z- -P1 ) EAX:406caaac EBX:40148e70 ECX:406ca754 EDX:00000000 ESI:406d0ca4 EDI:406cab1c Stack dump: 0x406caa70 (NTDLL.DLL.memcpy+0x3e1060): 406d0c9c 406cab20 406cab00 71188dc9 0x406caa80 (NTDLL.DLL.memcpy+0x3e1070): 4010b0f4 403b0814 00000000 406caa9c 0x406caa90 (NTDLL.DLL.memcpy+0x3e1080): 400c0f27 402786da 40273548 4026b208 0x406caaa0 (NTDLL.DLL.memcpy+0x3e1090): 401793e0 00000002 00000000 c0000025 0x406caab0 (NTDLL.DLL.memcpy+0x3e10a0): 00000001 406cae7c 40007f5e 00000000 0x406caac0 (NTDLL.DLL.memcpy+0x3e10b0): 40309451 016cab74 00000000 406cab20 0x406caad0 (NTDLL.DLL.memcpy+0x3e10c0): 0011: sel=008f base=4015f140 limit=00000fff 32-bit rw- Backtrace: =>0 0x4010b7ee (EXC_RtlRaiseException+0x28a in libntdll.dll.so) (ebp=406cab10) 1 0x40121c29 (NTDLL.DLL.__wine_call_from_32_regs+0xb5 in libntdll.dll.so) (ebp=406cae6c) 2 0x4010b55d (NTDLL.DLL.RtlRaiseException+0x5 in libntdll.dll.so) (ebp=406caed0) 3 0x499cd236 (URLMON.DLL.CopyBindInfo in urlmon.dll.so) (ebp=406caee0) 4 0x71119951 (BROWSEUI.DLL.EntryPoint+0x955 in C:\WINDOWS\SYSTEM\BROWSEUI.DLL) (ebp=406caf04) 5 0x711198fd (BROWSEUI.DLL.EntryPoint+0x901 in C:\WINDOWS\SYSTEM\BROWSEUI.DLL) (ebp=406cbf74) 6 0x7111988d (BROWSEUI.DLL.EntryPoint+0x891 in C:\WINDOWS\SYSTEM\BROWSEUI.DLL) (ebp=406ccfcc) 7 0x7112ac78 (BROWSEUI.DLL.DllGetClassObject+0x2471 in C:\WINDOWS\SYSTEM\BROWSEUI.DLL) (ebp=406ccfec) . . ( several winedbg commands snipped here ) . 0x499cd051 (URLMON.DLL..data+0xb051 in urlmon.dll.so): subl $4,%esp Wine-dbg>symbolfile /usr/local/lib/wine/urlmon.dll.so Reading symbols from file /usr/local/lib/wine/urlmon.dll.so Wine-dbg>list Enter path to file '': Wine-dbg>step Single stepping until exit from function, which has no line number information. . . . Whatever I do, even if winedbg makes a show of loading my symbols, it never seems to synch up with my source files, except maybe for libntdll.dll.so... anyone got ideas? Thanks, -gmt -- "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993

2 1

Re: [patch] Listview error handling
by Dimitrie O. Paun 26 Sep '02

26 Sep '02

On September 26, 2002 12:56 pm, Paul Rupe wrote: > This fixes a problem in my previous listview patch reported by Rein Klazes. > > Changelog: > Paul Rupe <prupe(a)myrealbox.com> > Remove freed sublist on failure in LISTVIEW_InsertItemT > + HDPA hdpaSubItems = NULL; I don't understand what you want to do. Why is this needed? Why did you change the code in the first place? -- Dimi.

1 0

Re: wine/dlls/comctl32 listview.c
by Rein Klazes 26 Sep '02

26 Sep '02

On Tue, 24 Sep 2002 22:20:02 -0500, you wrote: > ChangeSet ID: 5531 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/09/24 22:20:02 > > Modified files: > dlls/comctl32 : listview.c > > Log message: > Paul Rupe <prupe(a)myrealbox.com> > - Initialize memory to prevent crashes when -debugmsg +listview is on. > - Fix various array bounds related errors. > > Patch: http://cvs.winehq.com/patch.py?id=5531 This part causes trouble here: | @@ -6591,11 +6599,6 @@ | is_sorted = (lStyle & (LVS_SORTASCENDING | LVS_SORTDESCENDING)) && | !(lStyle & LVS_OWNERDRAWFIXED) && (LPSTR_TEXTCALLBACKW != lpLVItem->pszText); | | - nItem = DPA_InsertPtr( infoPtr->hdpaItems, | - is_sorted ? GETITEMCOUNT( infoPtr ) + 1 : lpLVItem->iItem, | - hdpaSubItems ); | - if (nItem == -1) goto fail; | - | if (!LISTVIEW_SetItemT(infoPtr, lpLVItem, isW)) goto fail; | | /* if we're sorted, sort the list, and update the index */ | @@ -6606,6 +6609,14 @@ | if (nItem == -1) goto fail; | } | | + /* Add the subitem list to the items array. Do this last in case we go to | + * fail during the above. | + */ | + nItem = DPA_InsertPtr( infoPtr->hdpaItems, | + is_sorted ? GETITEMCOUNT( infoPtr ) + 1 : lpLVItem->iItem, | + hdpaSubItems ); | + if (nItem == -1) goto fail; | + | (before there were no failed calls and the list is not sorted) I did not look very hard at the cause, but it looks that LISTVIEW_SetItemT() depends on the inserted subitems in function set_main_item. Rein. -- Rein Klazes rklazes(a)xs4all.nl

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel