Re: Join the effort: Porting wine-0.9.38
I wouldn't *submit* a non-working port, but here is a tarball for anyone who is interested. http://www.nabble.com/file/p11676042/unofficial_wine_0.9.38_port_for_obsd4.1release.tar.gz unofficial_wine_0.9.38_port_for_obsd4.1release.tar.gz I don't have time to improve this further, so good luck to everyone trying this. // Vortechz steven mestdagh wrote: Vortechz [2007-06-22, 09:22:47]: The wine port will not be submitted for quite some time since there are problems with threading and It is not forbidden to submit a tarball of a non-working port. That way, all your efforts which are currently scattered over a bunch of e-mails, are instantly available as a starting point, and it becomes much easier for people interested in helping out with the remaining problems to get involved. signal handling. Also, the original effort was made on 4.1-release and doesn't take into account some issues that apparently come up in -current with xenocara. To all who replied, I thank you for your interest. The port is not completely dead, but there won't be much work done, except maybe trying to get wine to run on librthread/RTHREADS. I hope that rthreads can get around the undefined behaviour in /usr/src/lib/libpthread/uthread/uthread_sigaltstack.c, causing EINVAL (I won't change libpthread!). Please correct me if you know better. -- View this message in context: http://www.nabble.com/Join-the-effort%3A-Porting-wine-0.9.38-tf3892781.html#a11676042 Sent from the openbsd user - ports mailing list archive at Nabble.com.
Re: Join the effort: Porting wine-0.9.38
The wine port will not be submitted for quite some time since there are problems with threading and signal handling. Also, the original effort was made on 4.1-release and doesn't take into account some issues that apparently come up in -current with xenocara. To all who replied, I thank you for your interest. The port is not completely dead, but there won't be much work done, except maybe trying to get wine to run on librthread/RTHREADS. I hope that rthreads can get around the undefined behaviour in /usr/src/lib/libpthread/uthread/uthread_sigaltstack.c, causing EINVAL (I won't change libpthread!). Please correct me if you know better. // Vortechz Vortechz wrote: After some initial trouble with wine (see thread http://www.nabble.com/wine-0.9.37-ktrace-tf3733527.html wine-0.9.37 ktrace ), I recieved patches from Michael Small and continued working...so by now wine-0.9.38 is at least doing something sensible... http://www.nabble.com/file/p11035940/screenshot_of_notepad.jpg screenshot_of_notepad.jpg Unfortunately, there is a lot of work left to do on this port. Also, I don't want to post the port tarball on the mailing list until I know for sure who will be maintaining the port as I can not maintain it. If you're interested in helping, please reply to me so I can estimate the interest. Also write down what you want to do (see below) and whether I should reply asap with a tarball attachment. Help is needed for... * Getting a proper ports Makefile...(neither of the involved porters have any previous experience of porting) * Sorting out all dependencies, and perhaps look for updated libraries * Review of patches (lots of __OpenBSD__ ifdefs may be found) * Sorting out some technical issues, for example whether to use sigaltstack or a bunch of sigaction calls. * Testing (i.e. playing games, if there are any OpenBSD users doing such things ;) Later there might also be the case of dealing with the so-called preloader (which sets up memory in a specific way) as there is a FreeBSD effort to port the so-far linux-only preloader code. Note that compiling the full wine port takes ~4 hours for me (but I have only 266 Mhz working for me) so I'd recommend that noone aims to test it on anything slower than that. // V.A. -- View this message in context: http://www.nabble.com/Join-the-effort%3A-Porting-wine-0.9.38-tf3892781.html#a11255524 Sent from the openbsd user - ports mailing list archive at Nabble.com.
Join the effort: Porting wine-0.9.38
After some initial trouble with wine (see thread http://www.nabble.com/wine-0.9.37-ktrace-tf3733527.html wine-0.9.37 ktrace ), I recieved patches from Michael Small and continued working...so by now wine-0.9.38 is at least doing something sensible... http://www.nabble.com/file/p11035940/screenshot_of_notepad.jpg screenshot_of_notepad.jpg Unfortunately, there is a lot of work left to do on this port. Also, I don't want to post the port tarball on the mailing list until I know for sure who will be maintaining the port as I can not maintain it. If you're interested in helping, please reply to me so I can estimate the interest. Also write down what you want to do (see below) and whether I should reply asap with a tarball attachment. Help is needed for... * Getting a proper ports Makefile...(neither of the involved porters have any previous experience of porting) * Sorting out all dependencies, and perhaps look for updated libraries * Review of patches (lots of __OpenBSD__ ifdefs may be found) * Sorting out some technical issues, for example whether to use sigaltstack or a bunch of sigaction calls. * Testing (i.e. playing games, if there are any OpenBSD users doing such things ;) Later there might also be the case of dealing with the so-called preloader (which sets up memory in a specific way) as there is a FreeBSD effort to port the so-far linux-only preloader code. Note that compiling the full wine port takes ~4 hours for me (but I have only 266 Mhz working for me) so I'd recommend that noone aims to test it on anything slower than that. // V.A. -- View this message in context: http://www.nabble.com/Join-the-effort%3A-Porting-wine-0.9.38-tf3892781.html#a11035940 Sent from the openbsd user - ports mailing list archive at Nabble.com.
Re: wine-0.9.37 ktrace
I just realized you're right, most of the trouble are due to the errors you point out. (I certainly have a made a fool out of myself by now) However, when I run make depend, comment out the building of dnsapi in dlls/Makefile and then run make, it seems to complete and ends up with the message Wine build complete as well as building the wine-pthread binary. Michael Small wrote: On Sun, May 13, 2007 at 12:38:30AM +0200, Vortechz Anderson wrote: wine-0.9.37 compiles on OpenBSD 4.1, except the dnsapi Not for me. Do you have patches? The dnsapi error is this one, right? cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wwrite-strings -Wpointer-arith -O2 -pipe -o name.o name.c In file included from name.c:46: dnsapi.h:143: error: syntax error before ns_msg dnsapi.h:144: error: syntax error before '*' token I could get this to compile by adding a LIB_DEPENDS on libbind and adding CFLAGS=-I/usr/local/include/bind But then I hit this error: cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC - Wall -pipe -fno-strict-aliasing -Wwrite-strings -Wpointer-arith -I/usr/local/incl ude/bind -o ipstats.o ipstats.c ipstats.c: In function `getNumRoutes': ipstats.c:630: error: `RTF_MULTICAST' undeclared (first use in this function) ipstats.c:630: error: (Each undeclared identifier is reported only once ipstats.c:630: error: for each function it appears in.) ipstats.c: In function `getRouteTable': ipstats.c:704: error: `RTF_MULTICAST' undeclared (first use in this function) Two places in this file he's looking at the routing table using sysctl and wishes to leave out entries that are not gateways or that are multicast. RTF_MULTICAST is defined in route.h in freebsd and linux but not in OpenBSD. Looking at this paragraph from the netstat man page, I though perhaps this wouldn't be an issue for OpenBSD, maybe the multicast check could be left out, maybe that's a separate table, but I'm uncertain: -g Show information related to multicast (group address) routing. By default, show the IP multicast virtual-interface and routing tables. If the -s option is also present, show multicast routing statistics. I left it out for myself and then hit this error... cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENT RANT -fPIC -Wall -pipe -fno-strict-aliasing -Wwrite-strings -Wpointer-arith -I/us r/local/include/bind -o cdrom.o cdrom.c cdrom.c: In function `DVD_ReadStructure': cdrom.c:1911: error: syntax error before s cdrom.c:1919: error: `s' undeclared (first use in this function) c This was a case where Linux, NetBSD, etc. have a typedef for the dvd_struct union in sys/cdio.h but OpenBSD has a regular union definition. Then I hit this... cc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENT RANT -fPIC -Wall -pipe -fno-strict-aliasing -Wwrite-strings -Wpointer-arith -I/us r/local/include/bind -o signal_i386.o signal_i386.c signal_i386.c:325: error: `T_MCHK' undeclared here (not in a function) signal_i386.c:325: error: enumerator value for `TRAP_x86_MCHK' not integer constan t signal_i386.c:349: error: `T_XMMFLT' undeclared here (not in a function) signal_i386.c:349: error: enumerator value for `TRAP_x86_CACHEFLT' not integer con stant signal_i386.c: In function `segv_handler': signal_i386.c:1186: error: duplicate case value signal_i386.c:1181: error: previously used here Here, although there's an if defined including __OpenBSD__ at the top of an enum, there are two definitions with slightly different names in OpenBSD trap.h than they try to use. I'm guessing there will be more stuff to come, but I was wondering if you already worked through all these yourself to get it to compile. I hope to get it to compile sometime this week, although I'm not sure if I'll be able to help with threading issues. The archives mention something about using vfork in a weird, linux specific way. Maybe that would be something to look at? If you look at .../libs/wine/mmap.c there are some troubling comments above and within try_mmap_fixed, as well as an #if defined(__NetBSD__). Execution leads to segfault. (Note: Generic kernel _has_ SYSV MSG/SHM/SEMand I have not forgot sysctl machdep.userldt=1) I know there are some issues about wine's use of kernel threads on OpenBSD. I am clueless about the true problem though. If possible, I would like some comments on the ktrace kdump. // V.A. 25268 ktrace RET ktrace 0 25268 ktrace CALL ... execve(0xcfbc4960,0xcfbc4ebc,0xcfbc4ec8) 25268 ktrace NAMI /usr/local/bin/wine 25268 wine NAMI /usr/libexec/ld.so 25268 wine EMUL native 25268 wine RET execve 0 25268 wine CALL issetugid() 25268 wine RET issetugid 0 25268
Re: wine-0.9.37, ntdll.so loading fails, gdb output included
Sorry about the delay (I'm sending this reply ASAP)
I have no real port yet, but I can provide two patches and a script which
should help
you build wine-0.9.37. Any issues with the configure should be related to
missing libraries
(install the proper packages to resolve that).
Note:
To me it seems that the inlined _dl_strlcpy in ld.so is part of the problem.
I don't understand
the inner workings of ld.so, and the inlined code makes it difficult to
debug (reading regs and guessing...?).
I'm still not sure if the $ORIGIN linker symbol (may be linux-specific ld.so
symbol?) is a problem,
or if it is supposed to work on OpenBSD 4.1.
The dnsapi of wine http://www.nabble.com/file/p10803006/patch.configure.ac
patch.configure.ac http://www.nabble.com/file/p10803006/patch.dlls_Makefile
patch.dlls_Makefile
http://www.nabble.com/file/p10803006/rustybuildscript.sh rustybuildscript.sh
does not build, hence a patch which simply disables building of dnsapi. If
we get
wine running, the dnsapi gets higher priority of course.
Good luck!
Kurt Miller-4 wrote:
Please email the list the updated port so that people who
may be interested in helping you can reproduce the problem.
On Saturday 19 May 2007 2:32:19 pm Vortechz wrote:
Jacob probably recognizes this:
Starting program: /usr/local/bin/wine /emul/w/windows/sol.exe
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 31915, thread 0x8891a000]
0x06a4dbec in _dl_malloc () from /usr/libexec/ld.so
(gdb) bt
#0 0x06a4dbec in _dl_malloc () from /usr/libexec/ld.so
#1 0x06a4e50a in _dl_opendir () from /usr/libexec/ld.so
#2 0x06a4e938 in _dl_find_shlib () from /usr/libexec/ld.so
#3 0x06a4ebe3 in _dl_load_shlib_hint () from /usr/libexec/ld.so
#4 0x06a4ee5c in _dl_load_shlib () from /usr/libexec/ld.so
#5 0x06a4c66d in dlopen () from /usr/libexec/ld.so
#6 0x0a667d54 in wine_dlopen (
filename=0x7d4d014a /usr/local/lib/../lib/wine/ntdll.dll.so,
flag=2,
error=0xcfbcaff0 \020°¼Ï, errorsize=1024) at loader.c:703
#7 0x0a667cb6 in wine_init (argc=16392, argv=0xcfbcafa0,
error=0xcfbcaff0 \020°¼Ï, error_size=1024) at loader.c:655
#8 0x1c000f92 in main (argc=2, argv=0xcfbcb46c) at main.c:111
* Now, I want to know more about what ld.so is doing:
(gdb) symbol /usr/libexec/ld.so
Load new symbol table from /usr/libexec/ld.so? (y or n) y
Reading symbols from /usr/libexec/ld.so...done.
(gdb) run /emul/w/windows/sol.exe
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/bin/wine /emul/w/windows/sol.exe
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 17606, thread 0x7f924000]
0x084f9bec in ?? () from /usr/libexec/ld.so
(gdb) bt
#0 0x084f9bec in ?? () from /usr/libexec/ld.so
#1 0x284f718c in ?? () from /usr/libexec/ld.so
#2 0x0008 in ?? ()
#3 0xcfbf5ee8 in ?? ()
#4 0x084fa50a in ?? () from /usr/libexec/ld.so
#5 0x4000 in dladdr ()
Cannot access memory at address 0x3fc8
* 0x3fc8 seem to be constant and appears at every try
* Next...I compiled ld.so and loaded symbols from ld.so and util.o
in /usr/src/libexec/ld.so/ (stupid move?) to get this:
[Switching to process 31541, thread 0x831a3000]
0x04468bec in _dl_malloc () from /usr/libexec/ld.so
(gdb) bt
#0 0x04468bec in _dl_malloc () from /usr/libexec/ld.so
#1 0x0446950a in _dl_opendir () from /usr/libexec/ld.so
#2 0x04469938 in _dl_find_shlib () from /usr/libexec/ld.so
#3 0x04469be3 in _dl_load_shlib_hint () from /usr/libexec/ld.so
#4 0x04469e5c in _dl_load_shlib () from /usr/libexec/ld.so
#5 0x0446766d in dlopen () from /usr/libexec/ld.so
#6 0x0d731d54 in wine_dlopen (
filename=0x877dd14a /usr/local/lib/../lib/wine/ntdll.dll.so,
flag=2,
error=0xcfbd5074 \224P½Ï, errorsize=1024) at loader.c:703
#7 0x0d731cb6 in wine_init (argc=16392, argv=0xcfbd5020,
error=0xcfbd5074 \224P½Ï, error_size=1024) at loader.c:655
#8 0x1c000f92 in ?? ()
#9 0x0002 in __stack_smash_handler ()
#10 0xcfbd54f0 in ?? ()
#11 0xcfbd5074 in ?? ()
#12 0x0400 in ?? ()
#13 0x3c00 in ?? ()
#14 0x0020 in __stack_smash_handler ()
#15 0x0030 in _dl_strdup ()
Cannot access memory at address 0x20
* I'm lost here.!
* util.c has a stack protector dummy...
void __stack_smash_handler(char [], int);
void
__stack_smash_handler(char func[], int damaged)
{
_dl_exit(127);
}
* _dl_exit is essentially (an asm wrapper for syscall) _exit(127)
* I don't know what to do now...except screaming for HLP.
Jacob Meuser-2 wrote:
On Sun, May 13, 2007 at 12:38:30AM +0200, Vortechz Anderson wrote:
wine-0.9.37 compiles on OpenBSD 4.1, except the dnsapi
Execution leads to segfault.
(Note: Generic kernel _has_ SYSV MSG/SHM/SEMand I
have not forgot sysctl machdep.userldt=1)
I know there are some issues about wine's use
Re: wine-0.9.37, ntdll.so loading fails...grr.....
Same patches, with links that can not be misunderstood(*sigh*) http://www.nabble.com/file/p10803006/patch.configure.ac patch.configure.ac http://www.nabble.com/file/p10803006/patch.dlls_Makefile patch.dlls_Makefile http://www.nabble.com/file/p10803006/rustybuildscript.sh rustybuildscript.sh -- View this message in context: http://www.nabble.com/wine-0.9.37-ktrace-tf3733527.html#a10803166 Sent from the openbsd user - ports mailing list archive at Nabble.com.
Re: wine-0.9.37, ntdll.so loading fails, gdb output included
Jacob probably recognizes this:
Starting program: /usr/local/bin/wine /emul/w/windows/sol.exe
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 31915, thread 0x8891a000]
0x06a4dbec in _dl_malloc () from /usr/libexec/ld.so
(gdb) bt
#0 0x06a4dbec in _dl_malloc () from /usr/libexec/ld.so
#1 0x06a4e50a in _dl_opendir () from /usr/libexec/ld.so
#2 0x06a4e938 in _dl_find_shlib () from /usr/libexec/ld.so
#3 0x06a4ebe3 in _dl_load_shlib_hint () from /usr/libexec/ld.so
#4 0x06a4ee5c in _dl_load_shlib () from /usr/libexec/ld.so
#5 0x06a4c66d in dlopen () from /usr/libexec/ld.so
#6 0x0a667d54 in wine_dlopen (
filename=0x7d4d014a /usr/local/lib/../lib/wine/ntdll.dll.so, flag=2,
error=0xcfbcaff0 \020°¼Ï, errorsize=1024) at loader.c:703
#7 0x0a667cb6 in wine_init (argc=16392, argv=0xcfbcafa0,
error=0xcfbcaff0 \020°¼Ï, error_size=1024) at loader.c:655
#8 0x1c000f92 in main (argc=2, argv=0xcfbcb46c) at main.c:111
* Now, I want to know more about what ld.so is doing:
(gdb) symbol /usr/libexec/ld.so
Load new symbol table from /usr/libexec/ld.so? (y or n) y
Reading symbols from /usr/libexec/ld.so...done.
(gdb) run /emul/w/windows/sol.exe
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/bin/wine /emul/w/windows/sol.exe
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 17606, thread 0x7f924000]
0x084f9bec in ?? () from /usr/libexec/ld.so
(gdb) bt
#0 0x084f9bec in ?? () from /usr/libexec/ld.so
#1 0x284f718c in ?? () from /usr/libexec/ld.so
#2 0x0008 in ?? ()
#3 0xcfbf5ee8 in ?? ()
#4 0x084fa50a in ?? () from /usr/libexec/ld.so
#5 0x4000 in dladdr ()
Cannot access memory at address 0x3fc8
* 0x3fc8 seem to be constant and appears at every try
* Next...I compiled ld.so and loaded symbols from ld.so and util.o
in /usr/src/libexec/ld.so/ (stupid move?) to get this:
[Switching to process 31541, thread 0x831a3000]
0x04468bec in _dl_malloc () from /usr/libexec/ld.so
(gdb) bt
#0 0x04468bec in _dl_malloc () from /usr/libexec/ld.so
#1 0x0446950a in _dl_opendir () from /usr/libexec/ld.so
#2 0x04469938 in _dl_find_shlib () from /usr/libexec/ld.so
#3 0x04469be3 in _dl_load_shlib_hint () from /usr/libexec/ld.so
#4 0x04469e5c in _dl_load_shlib () from /usr/libexec/ld.so
#5 0x0446766d in dlopen () from /usr/libexec/ld.so
#6 0x0d731d54 in wine_dlopen (
filename=0x877dd14a /usr/local/lib/../lib/wine/ntdll.dll.so, flag=2,
error=0xcfbd5074 \224P½Ï, errorsize=1024) at loader.c:703
#7 0x0d731cb6 in wine_init (argc=16392, argv=0xcfbd5020,
error=0xcfbd5074 \224P½Ï, error_size=1024) at loader.c:655
#8 0x1c000f92 in ?? ()
#9 0x0002 in __stack_smash_handler ()
#10 0xcfbd54f0 in ?? ()
#11 0xcfbd5074 in ?? ()
#12 0x0400 in ?? ()
#13 0x3c00 in ?? ()
#14 0x0020 in __stack_smash_handler ()
#15 0x0030 in _dl_strdup ()
Cannot access memory at address 0x20
* I'm lost here.!
* util.c has a stack protector dummy...
void __stack_smash_handler(char [], int);
void
__stack_smash_handler(char func[], int damaged)
{
_dl_exit(127);
}
* _dl_exit is essentially (an asm wrapper for syscall) _exit(127)
* I don't know what to do now...except screaming for HLP.
Jacob Meuser-2 wrote:
On Sun, May 13, 2007 at 12:38:30AM +0200, Vortechz Anderson wrote:
wine-0.9.37 compiles on OpenBSD 4.1, except the dnsapi
Execution leads to segfault.
(Note: Generic kernel _has_ SYSV MSG/SHM/SEMand I
have not forgot sysctl machdep.userldt=1)
I know there are some issues about wine's use of
kernel threads on OpenBSD. I am clueless about the
true
problem though. If possible, I would like
some comments on the ktrace kdump.
looks familiar.
before you even get to problems with threads, you have problems
with wine wanting to control where things are located.
I've got a port of 0.9.10 that gets a little farther than
what you got here. loads libwine and libc, but cannot load
ntdll.dll.so.
try setting 'ac_cv_cflags__Wl___section_start__interp_0x7bf00400=no'
in your environment before running configure and see if that
gets you any farther.
definitely not a trivial port.
// V.A.
25268 ktrace RET ktrace 0
25268 ktrace CALL
execve(0xcfbc4960,0xcfbc4ebc,0xcfbc4ec8)
25268 ktrace NAMI /bin/wine
25268 ktrace RET execve -1 errno 2 No such file
or directory
25268 ktrace CALL
execve(0xcfbc4960,0xcfbc4ebc,0xcfbc4ec8)
25268 ktrace NAMI /sbin/wine
25268 ktrace RET execve -1 errno 2 No such file
or directory
25268 ktrace CALL
execve(0xcfbc4960,0xcfbc4ebc,0xcfbc4ec8)
25268 ktrace NAMI /usr/bin/wine
25268 ktrace RET execve -1 errno 2 No such file
or directory
25268 ktrace CALL
execve(0xcfbc4960,0xcfbc4ebc,0xcfbc4ec8)
25268 ktrace NAMI /usr/sbin/wine
25268 ktrace RET execve -1 errno 2 No such file
or directory
25268 ktrace
Re: wine-0.9.37 ktrace
Multireply, really... Mikolaj: RTHREADS in kernel makes no difference at this point and the problem seems to be within ld.so, see below... wine-0.9.37 compiles on OpenBSD 4.1, except the dnsapi Michael: I don't care whether there are dlls which does not compile until wine is running, but feel free to patch dnsapi if you really want to. Execution leads to segfault. (Note: Generic kernel _has_ SYSV MSG/SHM/SEMand I have not forgot sysctl machdep.userldt=1) I know there are some issues about wine's use of kernel threads on OpenBSD. I am clueless about the true problem though. If possible, I would like some comments on the ktrace kdump. looks familiar. before you even get to problems with threads, you have problems with wine wanting to control where things are located. I've got a port of 0.9.10 that gets a little farther than what you got here. loads libwine and libc, but cannot load ntdll.dll.so. try setting 'ac_cv_cflags__Wl___section_start__interp_0x7bf00400=no' in your environment before running configure and see if that gets you any farther. Uhmnot really definitely not a trivial port. I found this, so I think one has to figure out whether ld.so works as it should, before even thinking about a wine port. I have been really discouraged by now, so don't expect any fireworks. http://www.kerneltraffic.org/wine/wn20030829_185.html#3 [...cut...] -- View this message in context: http://www.nabble.com/wine-0.9.37-ktrace-tf3733527.html#a10629252 Sent from the openbsd user - ports mailing list archive at Nabble.com.
Re: wine-0.9.37 ktrace
Uh, well...some progress coming up...but I don't know whether I'm getting closer or just being lucky ;) (I'm sorry if this post is unclear and/or of very little use. I'm not used to twisting/tweaking/porting software.) I put: 'ac_cv_cflags__Wl___section_start__interp_0x7bf00400=no' exported that as well, and ran configure --disable-win16 I believe the win16 might be responsible for the DOS low mem mapping sc***ing things up...but I haven't checked that, just to confuse myself and everyone else... I commented out the dnsapi line in dlls/Makefile... next I compiled: make depend ; make and tried running: ktrace wine-pthreads /emul/w/windows/sol.exe (Note: I try that because sol.exe runs under the current wine-99 OpenBSD port.) ...which created a *huge* ktrace.out file output from program was only wine: failed to initialize: File not found Here are the last four rows of code in main.c, which is the only place I can find that error msg: wine_pthread_set_functions( pthread_functions, sizeof(pthread_functions) ); wine_init( argc, argv, error, sizeof(error) ); fprintf( stderr, wine: failed to initialize: %s\n, error ); exit(1); After kdumping into text file, I did some greps for relevant things: grep -n '.so' wtf 4: 20251 wine-pthread NAMI /usr/libexec/ld.so 18: 20251 wine-pthread NAMI /var/run/ld.so.hints 30: 20251 wine-pthread NAMI /usr/local/lib/libwine.so.1.0 226: 20251 wine-pthread NAMI /usr/lib/libpthread.so.7.0 392: 20251 wine-pthread NAMI /usr/lib/libc.so.40.3 571: 20251 wine-pthread NAMI /usr/lib/libossaudio.so.3.0 grep -n not found wtf 100890: wine: failed to initialize: File not found About 150 lines above, /usr/local/lib/wine is opened, so there might be something missing there...? The closest access I can see is this: (note: 20251 is pid) 20251 wine-pthread NAMI /usr/local/lib/wine 20251 wine-pthread RET open 5 20251 wine-pthread CALL fstat(0x5,0xcfbc8420) grep -n 'lib' wtf 4: 20251 wine-pthread NAMI /usr/libexec/ld.so 27: 20251 wine-pthread NAMI $ORIGIN/../lib 30: 20251 wine-pthread NAMI /usr/local/lib/libwine.so.1.0 223: 20251 wine-pthread NAMI $ORIGIN/../lib 226: 20251 wine-pthread NAMI /usr/lib/libpthread.so.7.0 389: 20251 wine-pthread NAMI $ORIGIN/../lib 392: 20251 wine-pthread NAMI /usr/lib/libc.so.40.3 568: 20251 wine-pthread NAMI $ORIGIN/../lib 571: 20251 wine-pthread NAMI /usr/lib/libossaudio.so.3.0 1624: 20251 wine-pthread NAMI /usr/local/lib/../bin/wineserver 100687: 20251 wine-pthread NAMI /usr/local/lib/wine 100702: 20251 wine-pthread NAMI /usr/local/lib/wine 100723: 20251 wine-pthread NAMI /usr/local/lib/wine 100736: 20251 wine-pthread NAMI /usr/local/lib/wine Uh..$ORIGIN?? Another grep, which I won't paste here, is allocate memory, which seems to occupy every other line from ~2400 to ~100600. Example: wine-pthread CALL mmap(0x9f23,0x13f,0,0x1442,0x,0,0,0) wine-pthread RET mmap -1 errno 12 Cannot allocate memory I don't understand why mmap is called with eight args, maybe it's trivial for those who know. // V.A. -- View this message in context: http://www.nabble.com/wine-0.9.37-ktrace-tf3733527.html#a10633012 Sent from the openbsd user - ports mailing list archive at Nabble.com.
Re: wine-0.9.37 ktrace
Vortechz wrote: [...cut...] grep -n not found wtf 100890: wine: failed to initialize: File not found About 150 lines above, /usr/local/lib/wine is opened, so there might be something missing there...? The closest access I can see is this: (note: 20251 is pid) 20251 wine-pthread NAMI /usr/local/lib/wine 20251 wine-pthread RET open 5 20251 wine-pthread CALL fstat(0x5,0xcfbc8420) NOTE: I did run make install as well, although I forgot to mention that. -- View this message in context: http://www.nabble.com/wine-0.9.37-ktrace-tf3733527.html#a10633282 Sent from the openbsd user - ports mailing list archive at Nabble.com.
wine-0.9.37 ktrace
wine-0.9.37 compiles on OpenBSD 4.1, except the dnsapi Execution leads to segfault. (Note: Generic kernel _has_ SYSV MSG/SHM/SEMand I have not forgot sysctl machdep.userldt=1) I know there are some issues about wine's use of kernel threads on OpenBSD. I am clueless about the true problem though. If possible, I would like some comments on the ktrace kdump. // V.A. 25268 ktrace RET ktrace 0 25268 ktrace CALL execve(0xcfbc4960,0xcfbc4ebc,0xcfbc4ec8) 25268 ktrace NAMI /bin/wine 25268 ktrace RET execve -1 errno 2 No such file or directory 25268 ktrace CALL execve(0xcfbc4960,0xcfbc4ebc,0xcfbc4ec8) 25268 ktrace NAMI /sbin/wine 25268 ktrace RET execve -1 errno 2 No such file or directory 25268 ktrace CALL execve(0xcfbc4960,0xcfbc4ebc,0xcfbc4ec8) 25268 ktrace NAMI /usr/bin/wine 25268 ktrace RET execve -1 errno 2 No such file or directory 25268 ktrace CALL execve(0xcfbc4960,0xcfbc4ebc,0xcfbc4ec8) 25268 ktrace NAMI /usr/sbin/wine 25268 ktrace RET execve -1 errno 2 No such file or directory 25268 ktrace CALL execve(0xcfbc4960,0xcfbc4ebc,0xcfbc4ec8) 25268 ktrace NAMI /usr/local/bin/wine 25268 wine NAMI /usr/libexec/ld.so 25268 wine EMUL native 25268 wine RET execve 0 25268 wine CALL issetugid() 25268 wine RET issetugid 0 25268 wine CALL mprotect(0x2a6d5000,0x1000,0x1) 25268 wine RET mprotect 0 25268 wine CALL mmap(0,0x1000,0x3,0x1002,0x,0,0,0) 25268 wine RET mmap -1 errno 12 Cannot allocate memory 25268 wine PSIG SIGSEGV SIG_DFL code 1 addr=0xa6d7bec trapno=1 25268 wine NAMI wine.core _ Flyger tiden iväg? Fånga dagen med Yahoo! Mails inbyggda kalender. Dessutom 250 MB gratis, virusscanning och antispam. Få den på: http://se.mail.yahoo.com
