Date: Tue, 16 Nov 1999 15:00:02 -0800 (PST) From: Juergen Lock <nox@jelal.kn-bremen.de> To: freebsd-ports@FreeBSD.org Subject: Re: ports/14889: [PATCH] dynamic loading for WINE port Message-ID: <199911162300.PAA26974@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/14889; it has been noted by GNATS. From: Juergen Lock <nox@jelal.kn-bremen.de> To: Maxim Sobolev <sobomax@altavista.net> Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: ports/14889: [PATCH] dynamic loading for WINE port Date: Tue, 16 Nov 1999 21:32:15 +0100 On Tue, Nov 16, 1999 at 10:55:40AM +0200, Maxim Sobolev wrote: > Juergen Lock wrote: > > > In article <19991115024901.CEEF314C1C@hub.freebsd.org> you write: > > > > >Attached patch enables feature which allows WINE port to build dlls' > > >code in a shared library separately from the main WINE's code. This > > >should (at least teorethically) reduce WINE's memory footpring, > > >especially when several WINEs loaded simulateneously. > > > > Well actually if you're running several instances of the same statically > > linked program its entire text segment will already be shared anyway, > > shared libraries are only needed for the different-programs-using-the- > > same-lib case. So this will only make a difference if you have > > other programs besides wine itself that are also using libwine, but of > > course to prepare for that it might still be a good idea... (provided > > that it doesn't interfere with debugging, i.e. have you checked > > that wine's debugger works as well with the shared libwine? > > No, I did not tested it. Moreover I'm neither very confident with WINE > debugging facilities nor have much desire/time to learn it. Well if you know gdb (have you ever debugged unix programs?), its not very much different. Here's a simple test: wine -debug someprogram this will enter the debugger. then set a breakpoint on some win32 `syscall' the program will be using, like CreateFileA... use a 16 bit one if its a 16 bit program, for those you need to specify the `dll' name in addition to the name of the entrypoint, like KERNEL.OpenFile b CreateFileA (this is also used to just open a file btw, don't ask me why its called `Create'...) then continue: c if this doesn't work i.e. hangs kill it and try again, this time disabling the first breakpoint the -debug flag set before you `c'ontinue: disa 1 now the continue should start the program. when it reaches the CreateFileA breakpoint it will enter the debugger again, now you can try a backtrace, bt this should correctly list the symbols and line numbers, at least for those stack frames that point into wine code... (If your not sure you can mail me the backtrace of course.) > Please be my guest > (if you can of course) to test it. > Well my first priority on the port is the upgrade to 991114 and to adjust for the sigcontext change that was just MFC'd... (which should enable signal handling of a wine thats built on -stable to run correctly on -current as well.) > > As wine > > still is alpha and depends on meaningful bugreports from users this is > > a pretty important point, this is also why the port builds with -g > > and installs un-stripped...) > > Probably you are right, but it would be quite useful if we will provide way to > disable -g and install stripped binary (either in the form of -DDEBUG or > -DNODEBUG), because with all those debugging info wine binary bloating to the > size of several tens MB which is not what many users (including me ;) with disk > space constrains want it to be. Thus we will give user a choice which IMHO is > always better than no-choice case. > make NO_DEBUG=yes? could probably be added for that, with an appropriate warning... Regards, -- Juergen Lock <nox.foo@jelal.kn-bremen.de> (remove dot foo from address to reply) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911162300.PAA26974>