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

Re: winedbg doesn't find source files

by Vincent Béron

Le mer 11/08/2004 à 04:50, Mike Hearn a écrit : > Saulius Krasuckas wrote: > > I have had a long period of time not using the winedbg, so I cannot tell > > whether it is a regression. I am using "./configure && make depend && > > make" to build the Wine and then something like a "sudo make install", if > > that matters. > > > > I need an advice on how to setup winedbg the right way or an explanation, > > whether this is a bug or an advanced feature. TIA. > > Nope, it's a bug, something to do with STABS parsing I think. I have > reported it once to Eric but I think I didn't have enough info to help him. The original message had this line: fixme:dbghelp:elf_load_debug_info Unsupported Dwarf2 information So I suspect your Wine is compiled with Dwarf2 debug symbols rather than stabs+. Which gcc version was used? Vincent

Aug. 11, 2004

Re: winedbg doesn't find source files

by Mike Hearn

Saulius Krasuckas wrote: > I have had a long period of time not using the winedbg, so I cannot tell > whether it is a regression. I am using "./configure && make depend && > make" to build the Wine and then something like a "sudo make install", if > that matters. > > I need an advice on how to setup winedbg the right way or an explanation, > whether this is a bug or an advanced feature. TIA. Nope, it's a bug, something to do with STABS parsing I think. I have reported it once to Eric but I think I didn't have enough info to help him.

Aug. 11, 2004

config converting problem

by Henning Gerhardt

Hi all, a friend of me would update the wine package (20030813) from his SuSE 9.0 system to the latest availabe package for this system (20040716). After the update following error message appears on each start of wine: .... Warning: the specified Windows directory L"C:\\Windows" is not accessible. Warning: the specified System directory L"C:\\Windows\\System" is not accessible. He get me also an output of the first wine start: Created symlink /home/julian/.wine/dosdevices/c: -> ../${HOME}/.wine/fake_windows .... Created symlink /home/julian/.wine/dosdevices/y: -> ../${HOME} .... Warning: the specified Windows directory L"C:\\Windows" is not accessible. Warning: the specified System directory L"C:\\Windows\\System" is not accessible. After my advise to get me the content of his "~/.wine/dosdevices", he send me the following output: .... lrwxrwxrwx 1 julian users 28 10. Aug 18:50 c: -> ../%HOME%/.wine/fake_windows .... lrwxrwxrwx 1 julian users 9 10. Aug 18:50 y: -> ../%HOME% .... and he send me also his config file (snipped content): [Drive C] "Path" = "${HOME}/.wine/fake_windows" "Type" = "hd" "Label" = "fake_windows" "Filesystem" = "win95" ... [Drive Y] "Type" = "network" "Path" = "${HOME}" "Label" = "Home" "FS" = "win95" .... (I translated the german dialog with him to english) I think the problem is the ${HOME} variable which is not parsed / correct replaced during the convert process. Have anyone an idea to solve this problem ? Or is it only a problem of the SuSE distribution ? Regards, Henning

Aug. 11, 2004

Re: Small make compatibility changes (take 2)

by Mike Hearn

Alexandre Julliard wrote: > There are some makes that don't accept ':=', yes. I don't know whether > they would accept the current way or not, but that doesn't really > matter; since the current way is not portable to BSD we need to change > it anyway. The thing is, we need to replace it with something more > portable, not with something differently non-portable. Devils advocate: seeing as quite a few BSD users (at least the ones I know) already have gmake installed, it's free software and easily available in ports, why are we putting effort into portability to BSD make? Is there ever a situation where a user will have BSD make but be unable to use gmake? <g> thanks -mike

Aug. 11, 2004

Re: Small make compatibility changes (take 2)

by Vincent Béron

Le lun 09/08/2004 à 19:05, Alexandre Julliard a écrit : > Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > > > This seems to let users build and uninstall with BSD make. > > > > Changelog: > > Evaluate variable after replacement to build with BSD make. > > Unfortunately assignments with := are not portable either, so it's > only moving the problem. We probably need to restructure the makefiles > a bit to avoid that construct. FreeBSD's and OpenBSD's make, as well as GNU's make, seem to understand it OK (both from reading the docs and personal experiments). The current way of doing it doesn't work on FreeBSD's and OpenBSD's make, although it does work on GNU's make. Is there some other make which does accept the current way of doing it and does not accept my proposed way? Vincent

Aug. 11, 2004

Re: Small make compatibility changes (take 2)

by Alexandre Julliard

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > The current way of doing it doesn't work on FreeBSD's and OpenBSD's > make, although it does work on GNU's make. > > Is there some other make which does accept the current way of doing it > and does not accept my proposed way? There are some makes that don't accept ':=', yes. I don't know whether they would accept the current way or not, but that doesn't really matter; since the current way is not portable to BSD we need to change it anyway. The thing is, we need to replace it with something more portable, not with something differently non-portable. -- Alexandre Julliard julliard(a)winehq.org

Aug. 11, 2004

Re: Different X Displays and Wine

by Alexandre Julliard

Boaz Harrosh <boaz(a)hishome.net> writes: > [Q] Is it at-all possible to run Wine on 2 different $DISPLAY s, or is > the X-Server a Wine-Server resource. Will using a different user help? > Will using desktop mode help? Has any one been successful with letting > different network users connect and run Windows Apps under wine? How > did they Setup wine? How does Codeweavers do it with their Server > Product? That's not supported at the moment. You can run apps on two different displays by using a different WINEPREFIX for each, so that they don't share the same wineserver. Using different users would work too. -- Alexandre Julliard julliard(a)winehq.org

Aug. 11, 2004

Re: winedos: TSR (was MCB implementation)

by Alexandre Julliard

markus.amsler(a)oribi.org writes: > I'm trying to run a DOS application, that uses a TSR as a database driver. So I > donn't need TSR support in win32. I was just thinking how TSR support should > look like in wine, and that involves what should happen if you start a TSR > programm in a win32 shell. You can run already DOS programms in Win32 shells, > so it's naturally to try running a TSR. The problem is that launching a DOS program from a Win32 shell creates a new DOS box, so you can certainly run a TSR in there but your app won't be able to access it since it won't run in the same DOS box. So yes, you need to start the TSR from a DOS shell. But I suspect that a real DOS emulator may be a better choice for your app than Wine. -- Alexandre Julliard julliard(a)winehq.org

Aug. 11, 2004

Help with winemaker

by Veerendra Tippanagoudar

Hi, I am trying to port a project from windows to unix. I have installed redhat 7.0. After installing wine, i tried using winemaker on a set of modules that are interdependent. By modules, I mean sub-programs. When I run winemaker from the top of the project directory, it creates only Makefile and no configure, configure.in and Makefile.in scripts. Therefore I am not able to use ./configure --with-wine=/usr/local/wine. Since, I cannot run the ./configure command, I am not able to run the make command. Why are the configure and other files not being generated? Any help would really be appreciated. My project uses, C and C++ code. Thank you, Veerendra Tippanagoudar. P.S: The documentation online is not complete (especially the Makefile.in and Configure.in part). --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage!

Aug. 10, 2004

Re: Dockable Toolbar painting issue on SUSE 9.1

by Krishna Murthy

I have created a defect 2420 for this with the sample source and binary attachment. Krishna "Krishna Murthy" <krishna.murthy(a)guptaworldwide.com> wrote in message news:cfb4pt$ngt$1(a)sea.gmane.org... > I am facing the following issue on SUSe pro 9.1, but this issue is not > happening on RH 9.1. > - The MFC application has the dockable toolbar > - When I undock the toolbar to display ad popup window, the screen is not > refreshed and when I see the trace, the X11DRV_SetWindowPos() is called > ininitely. > > - Any one faced this issue? > - Could you please point me to the wine code source files related to toolbar > / dockable controls so that I could debug where the problem is occurring. > > The SUSe pro 9.1 has the follwoing library versions: > > XFree86-fonts-scalable-4.3.99.902-40 > XFree86-libs-4.3.99.902-40 > XFree86-Mesa-devel-4.3.99.902-40 > XFree86-fonts-75dpi-4.3.99.902-40 > XFree86-4.3.99.902-43.25 > XFree86-Mesa-4.3.99.902-40 > XFree86-devel-4.3.99.902-40 > XFree86-server-glx-4.3.99.902-40 > XFree86-server-4.3.99.902-43.25 > XFree86-Xvnc-4.3.99.902-40 > kdebase3-SuSE-9.1-18.1 > kdebase3-3.2.1-68.15 > > > Thanks in advance, > Krishna Murthy > Gupta Technologies LLC > TEL: (650) 596-4828 > E-mail: Krishna.Murthy(a)guptaworldwide.com > > > > >

Aug. 10, 2004