http://bugs.winehq.org/show_bug.cgi?id=14816
Rob rob1weld@aol.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major Keywords| |BugBuster, download, | |regression, source
--- Comment #3 from Rob rob1weld@aol.com 2008-08-10 20:39:07 --- It is my (non-expert in Kernel Programming) opinion that you are setting up the call to "sysenter" incorrectly (for Solaris 11 / OpenSolaris).
You are using a simple "#ifdef __sun" (in file signal_i386.c) to test for the Operating System and thus are grouping a few different series of Solaris together.
I searched the Internet for some assistance and came up with a few tidbits:
[osol-code] consolidation of x86 32-bit syscall implementations? http://archive.netbsd.se/?ml=opensolaris-code&a=2006-06&t=2097704
Not to forget the "generic" libc (which uses lcall $0x27,0 in S10 FCS and int 0x91 in later S10 updates and in OpenSolaris/Nevada).
* sysenter is only available on x86_32 with the supervisor_mode_kernel option enabled.
If you obtain SXCE (the development platform on which to compile OpenSolaris, see link above), download the OpenSolaris source code, and un-tar it into the recommended location you will have a file called: /aux0/testws/usr/src/lib/libc/i386/inc/SYS.h
The header of much of the OpenSolaris source code contains this License:
The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.
I can not post code from "SYS.h" since your file "signal_i386.c" is GPL 2.1+ and that License is not the same as Sun's CDDL.
What I can say is that Sun does not setup for "sysenter" (on Solaris 11) the same way that you setup for "sysenter" in the code contained in "signal_i386.c".
While I search for some GPL code to offer you I decided to test how well Solaris 11's sigaction() function would work and simply commented out your line:
/* #define sigaction(sig,new,old) solaris_sigaction(sig,new,old) */
so that your "#ifdef __sun" became a NULL and Sun's 'real' sigaction code would be used.
That produced an interesting result:
(gdb) c Continuing. err:iphlpapi:getNumWithOneHeader Unable to open '/proc/net/route' to count entries! err:iphlpapi:getRouteTable unimplemented! Could not load Mozilla. HTML rendering will be disabled. err:iphlpapi:getNumWithOneHeader Unable to open '/proc/net/route' to count entries! err:iphlpapi:getRouteTable unimplemented! err:module:load_builtin_dll failed to load .so lib for builtin L"msxml3.dll": ld.so.1: wine: fatal: libiconv.so.2: open failed: No such file or directory err:module:load_builtin_dll failed to load .so lib for builtin L"msxml3.dll": ld.so.1: wine: fatal: libiconv.so.2: open failed: No such file or directory wine: configuration in '/export/home/vmware/.wine' has been updated. Segmentation Fault (core dumped) bash-3.2$ err:module:attach_process_dlls "user32.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"C:\windows\system32\start.exe" failed, status 80000003
bash-3.2$
First issue, a "regular user" does not have read access to "/proc/net/route".
bash-3.2$ whoami notroot
bash-3.2$ ls -l /proc/net/route /proc/net/route: No such file or directory
bash-3.2$ ls -l /proc/net/ /proc/net/: No such file or directory
bash-3.2$ ls -l /proc/ total 188 dr-x--x--x 5 root root 864 Dec 27 1986 0 dr-x--x--x 5 root root 864 Dec 27 1986 1 (a few dozen more files, with numbers for names, but no "net") ...
Next issue, Solaris has "Firefox" not "Mozilla".
Next issue:
"err:module:load_builtin_dll failed to load .so lib for builtin L"msxml3.dll": ld.so.1: wine: fatal: ..."
It looks like "load_builtin_dll" is trying to load ".so". If instead that message means you are trying to find libiconv.so.2 or msxml3.dll then here are the results for those files:
bash-3.2$ ldd /opt/csw/lib/libiconv.so.2 libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1 libm.so.2 => /lib/libm.so.2
bash-3.2$ ldd /opt/gnu/wine/lib/wine/msxml3.dll.so libxml2.so.2 => /lib/libxml2.so.2 libpthread.so.1 => /lib/libpthread.so.1 libz.so => /lib/libz.so libiconv.so.2 => (file not found) libm.so.2 => /lib/libm.so.2 libsocket.so.1 => /lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 libxslt.so.1 => /usr/lib/libxslt.so.1 libwine.so.1 => (file not found) libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1 libmp.so.2 => /lib/libmp.so.2 libmd.so.1 => /lib/libmd.so.1 libscf.so.1 => /lib/libscf.so.1 libuutil.so.1 => /lib/libuutil.so.1 libgen.so.1 => /lib/libgen.so.1 bash-3.2$
So you appear to be looking for "msxml3.dll" when the file is called "msxml3.dll.so" (and there is no link from "msxml3.dll" to "msxml3.dll.so") and the shared library "msxml3.dll.so" was not linked with the correct "-R" to dynamically link libiconv, thus this: libiconv.so.2 => (file not found)
If the sigaction code does get fixed there will surely be other issues once we get past that point.
Due to all these issues I am bumping the "Severity" up one level (from "Normal" to "Major").