On Wednesday 16 June 2004 08:56, Rein Klazes wrote: > The source tree from which you compiled has to be reachable under one of > wine's configured Drive's. I normally open the source in an editor. Didn't work !? Still gives at startup: Unable to open file /winternl.h I created a sym-link for a drive: /home/oliver/.wine/dosdevices/s: -> /home/oliver/Software/Wine/wine/ ... and in .wine/config: [Drive S] "Path" = "/windows/c" "Type" = "hd" "Label" = "real winxp" ;"Filesystem" = "win95" I call it like this: ~/Software/Wine/wine/wine winedbg xst.exe -intstyle ise -ifn __projnav/stopwatch.xst -ofn stopwatch.syr When I set breakpoints, I get a lot of messages like this: [...] fixme:dbghelp:elf_new_wine_thunks Duplicate in kernel32<elf>: module.0<40529348-00000004> module<40529348-00000000> fixme:dbghelp:elf_new_wine_thunks Duplicate in kernel32<elf>: iDateW.4<40509aba-0000000c> iDateW<40509aba-00000000> [...] And especially: I can't se~/Software/Wine/wine/wine winedbg xst.exe -intstyle ise -ifn __projnav/stopwatch.xst -ofn stopwatch.syrt debug channels anymore in winedbg ?! Wine-dbg>set +file fixme:dbghelp:elf_new_wine_thunks Duplicate in imm32<elf>: name.0<4219a75c-00000012> name<4219a75c-00000000> [...] No symbols found for first_dll Can't get first_dll symbol Wine-dbg> Some clue what the problem could be ? If I could use winegdb from the source-tree to debug, would be quite good (see below). > That is to big. Hmmm, there may be an awful lot of file: traces. Is the > log with +relay significantly smaller? If not you must try to cut a good > piece from it. Yepp - normally the program in this configuration runs about 10sec. With +file,+ntdll and additionally +relay it run now +10h and still wasn't through! It created a 4MB bzip2'ed log-file. This could be 100gig or more uncompressed. +relay apparently creates a lot of output and bzip2 consumes 90% cpu to compress it. I have extracted some hopefully good parts. There are things like CreateFile and some steps after the same file is deleted again - strange stuff. Also some file:warnings. Should I put these already in a bug report ? It would be could if I could use winedbg, because I think it's more efficient. Then I can really sneak near the places where it happens and then trace it down. Finally it can't be such a difficult thing with this file, I think, or ? It just wants to be rewrite several times from the start. I was wondering why the previous data was put to all to zero? Perhaps it something like the lseek man says: [...] The lseek function allows the file offset to be set beyond the end of the existing end-of-file of the file (but this does not change the size of the file). If data is later written at this point, subsequent reads of the data in the gap return bytes of zeros (until data is actually written into the gap). [...] Cheerio, Oliver _______________________________________________ wine-users mailing list wine-users@xxxxxxxxxx http://www.winehq.org/mailman/listinfo/wine-users
