http://bugs.winehq.org/show_bug.cgi?id=18614
Summary: Problem with starting of wine or winecfg Product: Wine Version: 1.1.21 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P1 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: kh-pol@yandex.ru
When I start winecfg (even when there is no .wine in my home directory) error message emerges.
ktdr@jigsaw:~$ winecfg wine: created the configuration directory '/home/ktdr/.wine' Could not load Mozilla. HTML rendering will be disabled. wine: Unhandled page fault on write access to 0xeee52e96 at address 0x7d87dc36 (thread 000b), starting debugger... err:process:__wine_kernel_init boot event wait timed out err:winecfg:open_mountmgr failed to open mount manager err 2 ktdr@jigsaw:~$
http://bugs.winehq.org/show_bug.cgi?id=18614
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P2 Severity|critical |normal
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 2009-05-25 03:57:17 --- Have you compiled Wine on your own, or used a binary package?
http://bugs.winehq.org/show_bug.cgi?id=18614
Scott Ritchie scott@open-vote.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott@open-vote.org
--- Comment #2 from Scott Ritchie scott@open-vote.org 2009-06-07 23:34:26 --- If you'd like to try rebuilding the Ubuntu package from source, please follow the instructions here: http://wiki.winehq.org/Ubuntu
If building from vanilla source fixes the problem, but rebuilding the package from source doesn't, then we have a packaging issue.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #3 from Austin English austinenglish@gmail.com 2010-03-11 17:21:27 --- This is your friendly reminder that there has been no bug activity for 8 months. Is this still an issue in current (1.1.40 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=18614
spoonie sexy_b14@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sexy_b14@hotmail.com
--- Comment #4 from spoonie sexy_b14@hotmail.com 2010-07-10 03:30:00 --- I just compiled wine1.2 rc7 from source using a modfied abs (arch build system) script. compiles and installs fine but running winecfg I get this error when I hit the drives tab.
(in teminal)err:winecfg:open_mountmgr failed to open mount manager err 2
(in winecfg)Failed to connect to the mount manager, the drive configuration cannot be edited.
thanks guys
http://bugs.winehq.org/show_bug.cgi?id=18614
rmaz@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rmaz@gmx.net
--- Comment #5 from rmaz@gmx.net 2011-04-19 14:30:00 CDT --- I'm having the same annoying problem with wine versions 1.2.{1,2,3} and 1.3.x for months now on a Gentoo system where the dependencies were updated from rather old to very new over this time, both with distribution packages and manual installs. It used to work before that; I think it *may* have become broken when the X server went from using hal to udev; at least it happened around this time. But disabling hal support in wine, or enabling the hald daemon regardless, doesn't solve it.
However, a google search shows that the problems has appeared for people over the years. People are suspecting all kinds of things from home directory permissions to incompatible graphics drivers. A comment of one of the more lucky victims in https://bugs.launchpad.net/wine/+bug/296753 sums the general experience up nicely:
"Don't know what caused the problem. Don't know what fixed it."
I would suggest that the real bug here is the error message "open_mountmgr failed to open mount manager", which apparently is not very successful in connecting the wine-internal problem, whatever it is, to an external reality that the user has a chance to investigate and address.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #6 from Ken Sharp kennybobs@o2.co.uk 2011-04-19 15:10:20 CDT --- Without any useful debugging this will go nowhere, as it has done for nearly two years.
Doubtful a Wine bug even exists. I refer you back to my first sentence.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #7 from rmaz@gmx.net 2011-04-19 16:47:37 CDT --- It seems (as per programs/winecfg/drive.c) that winecfg attempts (and fails) to create or open (CreateFileW) a file MOUNTMGR_DOS_DEVICE_NAME that apparently (include/ddk/mountmgr.h) resolves to \\.\MountPointManager
I'm not sure where in the filesystem this file should be and why it should be there. Is this HAL stuff? This mountmgr.h file is (c) 2007 Alexandre Julliard, who recently took brief interest in the maybe related http://bugs.winehq.org/show_bug.cgi?id=25765
However, building --without-hal doesn't change a thing.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #8 from Ken Sharp kennybobs@o2.co.uk 2011-04-19 16:53:51 CDT --- Do you have a config.log from a "successful" build?
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #9 from rmaz@gmx.net 2011-04-19 17:08:48 CDT --- I do, but "The file you are trying to attach is 1218 kilobytes (KB) in size. Non-patch attachments cannot be more than 1000 KB." I'm splitting it in two parts.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #10 from rmaz@gmx.net 2011-04-19 17:12:48 CDT --- And for some reason the attachments ended up on bug 25765.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #11 from Ken Sharp kennybobs@o2.co.uk 2011-04-19 17:50:55 CDT --- Hmmm ok. In the future just compress it.
Do you have access to GCC 4.5? You could try that and see if it makes any difference.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #12 from rmaz@gmx.net 2011-04-19 19:38:33 CDT --- I just tried it with gcc 4.5.2. Takes longer to compile, but does not improve the situation. Error messages are exactly the same.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #13 from Ken Sharp kennybobs@o2.co.uk 2011-04-19 19:48:36 CDT --- And you completely cleaned ~/.wine ?
If not, try "rm -rf ~/.wine" and try again.
If you still have a problem, although I don't know how useful it will be, try WINEDEBUG=+relay,+seh,+tid winecfg &> winecfg.log
winecfg.log won't be small so you will need to compress it with decent compression and attach it here.
Also, what file system are you using?
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #14 from Dmitry Timoshkov dmitry@codeweavers.com 2011-04-19 22:05:59 CDT --- Does running Wine from the build tree work?
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #15 from rmaz@gmx.net 2011-04-20 05:45:53 CDT --- 1. Yes, I always removed ~/.wine before trying new things
2. Filesystem is ReiserFS 3.6
3. Running from the build tree shows same behavior
4. Running winecfg with "WINEDEBUG=+relay,+seh,+tid" WORKS, i.e., no error messages (a Gecko installer pops up and wants me to install Gecko, which I cancel for now), system32 is correctly populated (compare bug 25765 which now definitely seems to be related, if not the same), and I can open the Drive tab and autodedect or manually set my cdrom and other drives without error message. Removing .wine, and rerunning with an empty WINEDEBUG reliably reverts to the old behavior.
Likewise,
$ WINEDEBUG=+relay,+seh,+tid wine notepad
creates a correct .wine structure. I can then run winecfg without debug
$ winecfg
and don't get the drive problem.
INEDEBUG=+relay is apparently the critical setting and alone sufficient to ensure correct behavior. The others don't remove the problem, nor do +files or +mountmgr.
The requested log file is 182 MB and the best I can achieve (with xz -9e) is 1.5 MB, still too large to attach. Maybe without +relay, since this seems to remove the problem anyway?
I conclude that, at least in my case, this bug is a symptom of bug 25765.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #16 from Ken Sharp kennybobs@o2.co.uk 2011-04-20 14:52:29 CDT --- (In reply to comment #15)
- Filesystem is ReiserFS 3.6
Well I've tried a ReiserFS 3.6 for a WINEPREFIX so we can discount that, at least.
The requested log file is 182 MB and the best I can achieve (with xz -9e) is 1.5 MB, still too large to attach. Maybe without +relay, since this seems to remove the problem anyway?
Removing +relay probably won't tell us a great deal. You could try splitting it.
I conclude that, at least in my case, this bug is a symptom of bug 25765.
That should be resolved duplicate as the cause, whatever it is, is obviously the same.
Try just wineboot, if problem exists try rm -rf ~/.wine ; WINEDEBUG=+file wineboot &> wineboot.log
http://bugs.winehq.org/show_bug.cgi?id=18614
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sidewalker@lavabit.com
--- Comment #17 from Ken Sharp kennybobs@o2.co.uk 2011-04-20 14:53:01 CDT --- *** Bug 25765 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #18 from rmaz@gmx.net 2011-04-20 15:24:27 CDT --- Created an attachment (id=34247) --> (http://bugs.winehq.org/attachment.cgi?id=34247) winecfg.log part 1/2 as requested in comment #13
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #19 from rmaz@gmx.net 2011-04-20 15:25:20 CDT --- Created an attachment (id=34248) --> (http://bugs.winehq.org/attachment.cgi?id=34248) winecfg.log part 2/2 as requested in comment #13
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #20 from rmaz@gmx.net 2011-04-20 15:34:12 CDT ---
Removing +relay probably won't tell us a great deal. You could try splitting it.
Done.
Try just wineboot, if problem exists try
Same problem:
$ rm -rf ~/.wine; wineboot wine: created the configuration directory '/home/maz/.wine' err:rundll32:wWinMain Unable to load L"setupapi" wine: configuration in '/home/maz/.wine' has been updated.
rm -rf ~/.wine ; WINEDEBUG=+file wineboot &> wineboot.log
Attaching wineboot.log
Btw, using
$ rm -rf ~/.wine ; WINEDEBUG=+relay wineboot
again finishes without error (but my comment #8 to bug 25765 still applies).
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #21 from rmaz@gmx.net 2011-04-20 15:35:25 CDT --- Created an attachment (id=34249) --> (http://bugs.winehq.org/attachment.cgi?id=34249) wineboot.log as requested in comment #16
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #22 from Dmitry Timoshkov dmitry@codeweavers.com 2011-04-21 00:14:18 CDT --- (In reply to comment #21)
Created an attachment (id=34249)
--> (http://bugs.winehq.org/attachment.cgi?id=34249) [details]
wineboot.log as requested in comment #16
In that log there is no any attempt to open wine.inf file, try to figure out what's wrong with it.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #23 from rmaz@gmx.net 2011-04-21 05:11:35 CDT --- There is no wine.inf in WINEPREFIX, but I found this
$ ls -l /usr/local/share/wine/wine.inf -rw-r--r-- 1 root root 201287 Apr 20 20:34 /usr/local/share/wine/wine.inf
How would I find out "what's wrong with it"? Are the contents supposed to be system-specific? At any rate, its md5sum is
$ md5sum /usr/local/share/wine/wine.inf 39f39e0877afd9dacb0113d272229213 /usr/local/share/wine/wine.inf
In the header it says
;; This should be run through setupapi: ;; rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf
I could maybe try to do this manually, but I don't seem to have a rundll32 executable, only a rundll32.exe.so in /usr/local/lib/wine.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #24 from Dmitry Timoshkov dmitry@codeweavers.com 2011-04-21 06:20:28 CDT --- (In reply to comment #23)
There is no wine.inf in WINEPREFIX, but I found this
$ ls -l /usr/local/share/wine/wine.inf -rw-r--r-- 1 root root 201287 Apr 20 20:34 /usr/local/share/wine/wine.inf
There should be one in the build tree as well.
How would I find out "what's wrong with it"? Are the contents supposed to be system-specific? At any rate, its md5sum is
$ md5sum /usr/local/share/wine/wine.inf 39f39e0877afd9dacb0113d272229213 /usr/local/share/wine/wine.inf
No, its contents are not platform specific.
In the header it says
;; This should be run through setupapi: ;; rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf
I could maybe try to do this manually, but I don't seem to have a rundll32 executable, only a rundll32.exe.so in /usr/local/lib/wine.
Run it as you would do with any other Wine built-in application: wine rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #25 from Dmitry Timoshkov dmitry@codeweavers.com 2011-04-21 06:21:37 CDT --- Also perhaps adding +seh,+tid,+process in addition to +file could provide some useful additional information.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #26 from rmaz@gmx.net 2011-04-21 08:32:58 CDT --- (In reply to comment #24)
;; This should be run through setupapi: ;; rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf
I could maybe try to do this manually, but I don't seem to have a rundll32 executable, only a rundll32.exe.so in /usr/local/lib/wine.
Run it as you would do with any other Wine built-in application: wine rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf
Hm, that seems to bring us back to the orginal issue:
$ rm -rf .wine; wine rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf wine: created the configuration directory '/home/maz/.wine' err:rundll32:wWinMain Unable to load L"setupapi" wine: configuration in '/home/maz/.wine' has been updated. err:rundll32:wWinMain Unable to load L"setupapi.dll"
I'd guess that the reason wine.inf doesn't show up in the log is then that, since it fails to load this setupapi dll, it never gets to parse the later arguments. I'm guessing what the above command tries to do is dynload the specified library (setupapi.dll.so) and execute the function specified after the comma (InstallHinfSection) with the rest of the line passed as arguments to the function, yes?
I think I found the relevant section in programs/rundll32/rundll32.c:
/* Get the dll name and API EntryPoint */ WINE_TRACE("CmdLine=%s\n",wine_dbgstr_w(szCmdLine)); szDllName = get_next_arg(&szCmdLine); if (!szDllName || *szDllName==0) goto CLEANUP; WINE_TRACE("DllName=%s\n",wine_dbgstr_w(szDllName)); if ((szEntryPoint = strchrW(szDllName, ',' ))) *szEntryPoint++=0; else szEntryPoint = get_next_arg(&szCmdLine); WINE_TRACE("EntryPoint=%s\n",wine_dbgstr_w(szEntryPoint));
/* Load the library */ hDll=LoadLibraryW(szDllName); if (hDll) { win16 = FALSE; entry_point = get_entry_point32( hDll, szEntryPoint, &unicode ); } else { HINSTANCE16 dll = load_dll16( szDllName ); if (dll <= 32) { /* Windows has a MessageBox here... */ --> WINE_ERR("Unable to load %s\n",wine_dbgstr_w(szDllName)); <-- goto CLEANUP; } win16 = TRUE; unicode = FALSE; entry_point = get_entry_point16( dll, szEntryPoint ); }
Looks like it should write CmdLine, DllName, EntryPoint to the log before trying to open, but I don't see such lines in my wineboot.log. Which WINEDEBUG options do I need to get them? Is it the LoadLibraryW or the load_dll16 that does not produce the expected result?
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #27 from rmaz@gmx.net 2011-04-21 08:37:52 CDT --- Created an attachment (id=34263) --> (http://bugs.winehq.org/attachment.cgi?id=34263) wineboot.log as requested in comment #25
Output of
$ rm -rf .wine; WINEDEBUG=+file,+seh,+tid,+process wineboot &> wineboot.log
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #28 from rmaz@gmx.net 2011-04-21 08:52:09 CDT --- Created an attachment (id=34264) --> (http://bugs.winehq.org/attachment.cgi?id=34264) output of failing "make test"
I just realized that there is a "test" target for the build. Of course it fails (I get a Program Error popup about a serious advapi32_test.exe failure which I close). Attaching output of
wine-1.2.3 $ rm -rf ~/.wine; make test &> make_test.log
Does that tell us anything new?
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #29 from Ken Sharp kennybobs@o2.co.uk 2011-04-21 14:49:47 CDT --- 000b:trace:process:create_process_impl app L"C:\windows\system32\rundll32.exe" cmdline L"C:\windows\system32\rundll32.exe setupapi,InstallHinfSection DefaultInstall 128 \\?\unix/usr/local/bin/../share/wine/wine.inf"
Does /usr/local/share/wine/wine.inf exist? Are the permissions correct?
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #30 from rmaz@gmx.net 2011-04-21 15:28:56 CDT ---
Does /usr/local/share/wine/wine.inf exist? Are the permissions correct?
You can see them in comment #23. I don't know what they are supposed to be.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #31 from rmaz@gmx.net 2011-04-21 15:50:26 CDT --- Is there maybe a rundll32 command with a simpler dll I could try? I'd be curious to learn whether this works with other dlls. Maybe it's not a setup problem, but a dll loading problem?
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #32 from Dmitry Timoshkov dmitry@codeweavers.com 2011-04-21 23:02:16 CDT --- It looks like you are using wine-wine-1.2.3 and install wine binaries to /usr/local. I'd suggest to: 1. uninstall all traces of old Wine installs 2. use Wine git (or at least 1.3.18) 3. do all investigation running from the build tree
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #33 from Dmitry Timoshkov dmitry@codeweavers.com 2011-04-21 23:19:27 CDT --- (In reply to comment #27)
Created an attachment (id=34263)
--> (http://bugs.winehq.org/attachment.cgi?id=34263) [details]
wineboot.log as requested in comment #25
Output of
$ rm -rf .wine; WINEDEBUG=+file,+seh,+tid,+process wineboot &> wineboot.log
According to the above log there was an exception while running rundll32. Please add +rundll32,+module or try to run it under winedbg.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #34 from rmaz@gmx.net 2011-04-22 07:06:34 CDT --- Created an attachment (id=34284) --> (http://bugs.winehq.org/attachment.cgi?id=34284) wineboot.log as requested in comment #33
Ok, uninstalled wine-1.2.3, switched to wine-1.3.18. There is now a configure WARNING about "prelink" missing, "make test" fails as before (first error about loading setupapi), but without opening a popup. Didn't "make install" and running from build tree. Problem as described persists, adding +relay makes it go away as before.
Attaching output from
wine-1.3.18 $ rm -rf ~/.wine; WINEDEBUG=+file,+seh,+tid,+process,+rundll32,+module ./wine wineboot &> wineboot.log
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #35 from Dmitry Timoshkov dmitry@codeweavers.com 2011-04-23 00:12:08 CDT --- Here it is what I think makes the rundll32 start up fail:
0010:trace:module:process_attach (L"winspool.drv",(nil)) - START 0010:trace:module:MODULE_InitDLL (0x7e3d0000 L"winspool.drv",PROCESS_ATTACH,(nil)) - CALL 0010:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7e21bf70 ip=7e21bf70 tid=0010 0010:trace:seh:raise_exception info[0]=00000000 0010:trace:seh:raise_exception info[1]=ffffffff 0010:trace:seh:raise_exception eax=00000008 ebx=7e244ff4 ecx=7e244ff4 edx=7e21a320 esi=00000008 edi=0033efb2 0010:trace:seh:raise_exception ebp=7e246d00 esp=0033ef68 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00210283 0010:trace:seh:call_stack_handlers calling handler at 0x7efce220 code=c0000005 flags=0 0010:trace:seh:__regs_RtlUnwind code=c0000005 flags=2 0010:trace:seh:__regs_RtlUnwind calling handler at 0x7efb76a0 code=c0000005 flags=2 0010:trace:seh:__regs_RtlUnwind handler at 0x7efb76a0 returned 1 0010:trace:module:MODULE_InitDLL (0x7e3d0000,PROCESS_ATTACH,(nil)) - RETURN 1 0010:trace:module:MODULE_InitDLL (0x7e3d0000 L"winspool.drv",PROCESS_DETACH,(nil)) - CALL 0010:trace:module:MODULE_InitDLL (0x7e3d0000,PROCESS_DETACH,(nil)) - RETURN 1 0010:warn:module:process_attach Initialization of L"winspool.drv" failed
As a next step you could make PROCESS_ATTACH in winspool.drv do nothing, and see if that helps.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #36 from Dmitry Timoshkov dmitry@baikal.ru 2011-04-27 23:09:17 CDT --- Is there any progress on this?
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #37 from rmaz@gmx.net 2011-04-30 13:14:45 CDT --- (In reply to comment #36)
Is there any progress on this?
Not from my side. I'm not sure what you suggested there.
http://bugs.winehq.org/show_bug.cgi?id=18614
Valentin David valentin.david@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |valentin.david@gmail.com
--- Comment #38 from Valentin David valentin.david@gmail.com 2011-05-10 14:28:50 CDT --- I had the same problem until I recompiled without cups support. Now everything seems to work.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #39 from Austin English austinenglish@gmail.com 2011-05-10 16:43:58 CDT --- (In reply to comment #38)
I had the same problem until I recompiled without cups support. Now everything seems to work.
Do you have any network printers?
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #40 from Valentin David valentin.david@gmail.com 2011-05-10 16:58:42 CDT --- (In reply to comment #39)
Do you have any network printers?
I have a backend script to pipe to a lp command through a ssh, and a virtual pdf. But it does not matter, the bug also happens when the cups service is not started.
http://bugs.winehq.org/show_bug.cgi?id=18614
shane.wilkins@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |shane.wilkins@gmail.com
--- Comment #41 from shane.wilkins@gmail.com 2011-07-01 08:43:27 CDT --- I think I'm having the same problem here.
OS X 10.6.8 Wine 1.3.23 (installed through macports)
I've deleted the wine prefix several times, and uninstalled and reinstalled wine itself (both the stable and developmental builds) and still no joy.
Here's what happens:
lilsheezy:~ shane$ rm -rf ~/.wine lilsheezy:~ shane$ winecfg wine: created the configuration directory '/Users/shane/.wine'
and then after a couple minutes it will eventually say:
err:process:__wine_kernel_init boot event wait timed out
If I kill the wine process before it times out I get:
/opt/local/bin/wine: line 5: 35930 Terminated DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib" "/opt/local/libexec/wine/wine" "$@" /opt/local/libexec/wine/../../lib/../bin/wine: line 5: 35935 Terminated DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib" "/opt/local/libexec/wine/wine" "$@" lilsheezy:~ shane$ /opt/local/libexec/wine/../../lib/../bin/wine: line 5: 35939 Terminated DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib" "/opt/local/libexec/wine/wine" "$@" /opt/local/libexec/wine/../../lib/../bin/wine: line 5: 35937 Terminated DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib" "/opt/local/libexec/wine/wine" "$@"
I am kind of new to wine, and so I don't know how to give any more specific debugging information than that.
http://bugs.winehq.org/show_bug.cgi?id=18614
Steve Dawson sdawson@pa.metrocast.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sdawson@pa.metrocast.net
--- Comment #42 from Steve Dawson sdawson@pa.metrocast.net 2012-07-07 09:15:07 CDT --- (In reply to comment #41)
I think I'm having the same problem here.
OS X 10.6.8 Wine 1.3.23 (installed through macports)
I've deleted the wine prefix several times, and uninstalled and reinstalled wine itself (both the stable and developmental builds) and still no joy.
Here's what happens:
lilsheezy:~ shane$ rm -rf ~/.wine lilsheezy:~ shane$ winecfg wine: created the configuration directory '/Users/shane/.wine'
and then after a couple minutes it will eventually say:
err:process:__wine_kernel_init boot event wait timed out
If I kill the wine process before it times out I get:
/opt/local/bin/wine: line 5: 35930 Terminated DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib" "/opt/local/libexec/wine/wine" "$@" /opt/local/libexec/wine/../../lib/../bin/wine: line 5: 35935 Terminated DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib" "/opt/local/libexec/wine/wine" "$@" lilsheezy:~ shane$ /opt/local/libexec/wine/../../lib/../bin/wine: line 5: 35939 Terminated DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib" "/opt/local/libexec/wine/wine" "$@" /opt/local/libexec/wine/../../lib/../bin/wine: line 5: 35937 Terminated DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib" "/opt/local/libexec/wine/wine" "$@"
I am kind of new to wine, and so I don't know how to give any more specific debugging information than that.
I believe this is a gcc related problem.
I have had the same issue, the wine prefix doesn't get populated, workarounds such as compiling without cups or creating the prefix with +relay worked but just masked the underlying issue. One of the other issues I had was winemenubuilder would crash with a segfault in zlib. ( backtrace attached ) Googling eventually led me here http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
Recompiling the 32 bit zlibs with the -mstackrealign flag fixed the winemenubuilder problem and seems to have fixed the prefix creation issue as well. I have tested this on 1.5.4 and 1.5.8
Using this gcc flag has also solved some unrelated issues, see here http://bugs.winehq.org/show_bug.cgi?id=30246
Hopefully someone can reproduce the fix :)
Regards.
P.S. output of gcc -v
Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.6.0/configure --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-c99 --enable-long-long --enable-clocale=gnu --enable-languages=c,c++ --disable-libstdcxx-pch Thread model: posix gcc version 4.6.0 (GCC for Cross-LFS 4.6.0.20110517)
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #43 from Steve Dawson sdawson@pa.metrocast.net 2012-07-07 09:16:18 CDT --- Created attachment 40908 --> http://bugs.winehq.org/attachment.cgi?id=40908 zlib segfault when called by winmenubuilder referenced in comment #42
http://bugs.winehq.org/show_bug.cgi?id=18614
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |frederic.delanoy@gmail.com
--- Comment #44 from Frédéric Delanoy frederic.delanoy@gmail.com --- Is this still an issue in latest wine (1.7.17 or later)?
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #45 from Steve Dawson sdawson@pa.metrocast.net --- (In reply to Frédéric Delanoy from comment #44)
Is this still an issue in latest wine (1.7.17 or later)?
I haven't seen this issue since my post on 07/2012, I don't believe it was a wine problem, more likely an issue with gcc compiling 32 bit code on x86_64.
I am currently running 1.7.17.
Regards
Steve.
http://bugs.winehq.org/show_bug.cgi?id=18614
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #46 from Frédéric Delanoy frederic.delanoy@gmail.com --- (In reply to Steve Dawson from comment #45)
(In reply to Frédéric Delanoy from comment #44)
Is this still an issue in latest wine (1.7.17 or later)?
I haven't seen this issue since my post on 07/2012, I don't believe it was a wine problem, more likely an issue with gcc compiling 32 bit code on x86_64.
I am currently running 1.7.17.
Regards
Steve.
Assumed fixed.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #47 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Frédéric Delanoy from comment #46)
(In reply to Steve Dawson from comment #45)
(In reply to Frédéric Delanoy from comment #44)
Is this still an issue in latest wine (1.7.17 or later)?
I haven't seen this issue since my post on 07/2012, I don't believe it was a wine problem, more likely an issue with gcc compiling 32 bit code on x86_64.
I am currently running 1.7.17.
Regards
Steve.
Assumed fixed.
I'd say worksforme since he is not the original reporter and also he said the problem was probably not wine.
http://bugs.winehq.org/show_bug.cgi?id=18614
--- Comment #48 from Frédéric Delanoy frederic.delanoy@gmail.com --- (In reply to Bruno Jesus from comment #47)
(In reply to Frédéric Delanoy from comment #46)
(In reply to Steve Dawson from comment #45)
(In reply to Frédéric Delanoy from comment #44)
Is this still an issue in latest wine (1.7.17 or later)?
I haven't seen this issue since my post on 07/2012, I don't believe it was a wine problem, more likely an issue with gcc compiling 32 bit code on x86_64.
I am currently running 1.7.17.
Regards
Steve.
Assumed fixed.
I'd say worksforme since he is not the original reporter and also he said the problem was probably not wine.
User from comment 5 could reproduce it, so worksforme is not appropriate here IMO.
https://bugs.winehq.org/show_bug.cgi?id=18614
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #49 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.18.
-
wine-bugs＠winehq.org