http://bugs.winehq.org/show_bug.cgi?id=14920
Summary: Wine crashes when running Jezzball Product: Wine Version: unspecified Platform: Macintosh OS/Version: Mac OS X 10.5 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: johnmusbach1@gmail.com
Created an attachment (id=15496) --> (http://bugs.winehq.org/attachment.cgi?id=15496) crash log
Running Mac OS X 10.5.4 on a MacBook 2.16Ghz Intel Core 2 Duo with 2GB RAM and Wine 1.0. When Jezzball from the Microsoft Entertainment Pack is starting to load via Wine, Wine eventually crashes with the output shown in the attached log.
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #1 from Austin English austinenglish@gmail.com 2008-08-20 10:08:45 --- err:wgl:X11DRV_wglGetProcAddress No libGL on this box - disabling OpenGL support ! err:module:import_dll Library ntoskrnl.exe (which is needed by L"c:\windows\system32\mountmgr.sys") not found
Looks like a broken setup...Where did you get wine from?
http://bugs.winehq.org/show_bug.cgi?id=14920
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #15496|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #2 from John Musbach johnmusbach1@gmail.com 2008-08-20 13:32:30 --- I got it from http://prdownloads.sourceforge.net/wine/wine-1.0.tar.bz2
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #3 from Austin English austinenglish@gmail.com 2008-08-20 15:01:18 --- (In reply to comment #2)
I got it from http://prdownloads.sourceforge.net/wine/wine-1.0.tar.bz2
Run ./configure and fix any compile errors.
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #4 from John Musbach johnmusbach1@gmail.com 2008-08-20 15:08:36 --- Created an attachment (id=15506) --> (http://bugs.winehq.org/attachment.cgi?id=15506) configure log
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #5 from John Musbach johnmusbach1@gmail.com 2008-08-20 15:09:57 --- I don't get any errors when running ./configure, unless what I thought are optional dependency warning messages at the end are really messages informing me of required dependencies? Those weren't required with previous versions of wine... (see configure log)
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #6 from Dmitry Timoshkov dmitry@codeweavers.com 2008-08-20 21:50:57 --- (In reply to comment #5)
I don't get any errors when running ./configure, unless what I thought are optional dependency warning messages at the end are really messages informing me of required dependencies? Those weren't required with previous versions of wine... (see configure log)
The dependencies are optional, but if you ignore the warning you are on your own if something doesn't work. Anyway, that's not related to the original OpenGL problem, configure successfully finds OpenGL libraries. Have you tried to compile and run Wine with your app?
http://bugs.winehq.org/show_bug.cgi?id=14920
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.0.0
http://bugs.winehq.org/show_bug.cgi?id=14920
John Musbach johnmusbach1@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.0.0 |unspecified
--- Comment #7 from John Musbach johnmusbach1@gmail.com 2008-08-20 22:12:13 --- Yes, the crash log is the end result of wine being compiled after that ./configure run. I'm not even sure why Wine is trying to load OpenGL, it shouldn't be needed for Jezzball which was a 2D 90s game (http://www.theblog.ca/wp-content/uploads/2006/06/jezzball.jpg).
http://bugs.winehq.org/show_bug.cgi?id=14920
James Hawkins truiken@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.0.0
--- Comment #8 from James Hawkins truiken@gmail.com 2008-08-20 22:13:26 --- Don't change the version.
http://bugs.winehq.org/show_bug.cgi?id=14920
John Musbach johnmusbach1@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.0.0 |unspecified
--- Comment #9 from John Musbach johnmusbach1@gmail.com 2008-08-20 22:15:24 --- Don't change the version of what? The configure log and the crash log are both from Wine 1.0.
http://bugs.winehq.org/show_bug.cgi?id=14920
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.0.0
--- Comment #10 from Dmitry Timoshkov dmitry@codeweavers.com 2008-08-20 22:17:12 --- (In reply to comment #7)
Yes, the crash log is the end result of wine being compiled after that ./configure run. I'm not even sure why Wine is trying to load OpenGL, it shouldn't be needed for Jezzball which was a 2D 90s game (http://www.theblog.ca/wp-content/uploads/2006/06/jezzball.jpg).
Wine uses OpenGL for its ddraw implementation. Probably help from one of our ddraw/d3d/opengl hackers is needed to figure out the problem.
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #11 from James Hawkins truiken@gmail.com 2008-08-20 22:18:03 --- Before you submit any new comments, look at the version field of the bug report...you keep changing it to unspecified when it should be at 1.0.0.
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #12 from John Musbach johnmusbach1@gmail.com 2008-08-21 01:51:39 --- (In reply to comment #11)
Before you submit any new comments, look at the version field of the bug report...you keep changing it to unspecified when it should be at 1.0.0.
Ohh I see, sorry about that -- it should be fixed now :)
http://bugs.winehq.org/show_bug.cgi?id=14920
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
--- Comment #13 from Vincent Povirk madewokherd@gmail.com 2008-08-21 19:36:03 --- DirectDraw not running on OS X is a known problem documented in the faq: http://wiki.winehq.org/FAQ#head-5bba8bcc401e4ee1d3b733501f98768a47e661e6
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #14 from John Musbach johnmusbach1@gmail.com 2008-08-21 20:02:41 --- So then what this comes down to is that Jezzball uses DirectDraw and since DirectDraw is broken when wine is compiled on Mac OS X Jezzball just plain won't work with wine until the DirectDraw implementation is fixed to work on Mac OS X?
http://bugs.winehq.org/show_bug.cgi?id=14920
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|Macintosh |PC
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #15 from Jeffrey Pfau archaemic.spam@gmail.com 2009-06-21 15:01:36 --- Created an attachment (id=21939) --> (http://bugs.winehq.org/attachment.cgi?id=21939) simtower crash log
I get a similar crash when I try to run most 16-bit applications on Mac. I don't think I've found one that doesn't crash, but all of what I'm running are old games. However, I'm fairly certain that at least one of them (SimTower) doesn't use DirectDraw, because I tried to debug into SimTower once under Linux to fix a drawing problem, and I concluded it used GDI based on the calls it was making. I also just dissected the binary and found reference to GDI, but not to DDraw. I get a similar crash log to the one posted here, except without all the GL problems. Attached is the log.
This has happened to me with every version of Wine I've tried on my Mac (OS X 10.5.7 right now, the attached log is with Wine 1.1.23, but it's the same with previous versions)
http://bugs.winehq.org/show_bug.cgi?id=14920
Jeffrey Pfau archaemic.spam@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #21939|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=14920
Jeffrey Pfau archaemic.spam@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |archaemic.spam@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=14920
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #16 from Jörg Höhle hoehle@users.sourceforge.net 2009-06-22 09:58:00 --- Let me consider the present issue as a sort of meta-bug for 16bit apps crashing in wine on read access to 0xffffffff in winevdm on MacOS. I don't need a duplicate entry just to report that among other applications, Pharaoh's demo setup.exe crashes on MacOS 10.5.6+7 (while the application itself works fine when copied from a Linux install) in wine built with gcc-4.2 from the Mac Xcode install DVD, without Fink nor MacPorts.
Maybe somebody could change the subject line accordingly?
Alexandre Julliard wrote several times now, e.g. in bug #13601:
Note also that Xcode 3.0 and 3.1 both miscompile the 16-bit relay code, so currently the only way to get a fully functional Wine is to build with Xcode 2.x.
Xcode is a sort of red herring to me, as it's not the GUI, but presumably the gcc inside gccX.Y.pkg, distributed as part of the Xcode SDK, that miscompiles wine.
The location of Apple's modified GNU software (gcc is part of it) is http://www.opensource.apple.com/source/gcc/ http://www.opensource.apple.com/ contains the source tarballs of Apple's open source binaries and a mapping from Mac OS and Xcode release to packages and their build numbers. This shows that both Xcode 2.5 and 3.x contain gcc 4.0.1, although in different builds: gcc 4.0.1 dev30+2.5.7 build 5465 ChangeLog:2005-09-28 gcc 4.0.1 dev25 build 5370 ChangeLog:2005-09-28 http://www.opensource.apple.com/tarballs/gcc/gcc-5370.tar.gz
So I invite all you Mac users to compile gcc and report here whether switching gcc-4.0.1 builds solves any 16bit issue with wine. If yes, we could consecutively try to locate the exact cause of the regression in gcc.
Knowing which version of gcc works and which doesn't might help find the exact cause of the bug. Maybe that's even something the gcc maintainers need to know, if somebody can isolate it?
I filed Radar bug 5935237 a couple of months ago, but I haven't heard anything back.
Alexandre, would you mind making the details of your bug report and findings publicly readable for the rest of us via Open Radar? http://openradar.appspot.com/faq
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #17 from Alexandre Julliard julliard@winehq.org 2009-06-22 10:35:40 --- Created an attachment (id=21947) --> (http://bugs.winehq.org/attachment.cgi?id=21947) Asm fragment to demonstrate the Apple linker bug.
The bug is actually not in gcc, but in the linker. To see the bug with the attached callw.s:
$ gcc -o callw callw.s $ otool -t -v callw
and check to which label the callw goes. It should go to correct_dest if the linker works.
http://bugs.winehq.org/show_bug.cgi?id=14920
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Wine crashes when running |Win16 programs crash with |Jezzball |Wine built with newer XCode | |on Mac OS X
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #18 from Vitaliy Margolen vitaliy@kievinfo.com 2009-06-22 21:22:05 --- Sounds like invalid bug to me then (not Wine problem).
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #19 from Jörg Höhle hoehle@users.sourceforge.net 2009-06-23 05:09:54 --- Invalid indeed to the purist. My suggestion is to nevertheless keep it open, so people can find it given good keywords: winevdm C:\windows\system32\winevdm.exe MacOS "page fault on read access to 0xffffffff" old 16bit application
This issue is and will be a recurring problem to Mac users, and may generate lots of somehow undue "garbage" ratings in AppDB. Undue because in the case of Pharaoh, only the installer is affected, but people on MacOS only have no means to detect that.
For AppDB, it becomes important to know how a user built or obtained wine. Perhaps Kronenberg uses the old Xcode (or at least its linker), I haven't checked. My brand new Mac with 10.5.7 and Xcode 3.x does not qualify. As for myself, I'm thankful for any pointers on how to get hold of the linker from the old Xcode 2.5 so that I can try and build a wine for MacOS working with 16 bit apps. The linker does not seem to be a GNU package on http://www.opensource.apple.com/
BTW, who is authorized to edit the completely misleading and outdated http://wiki.winehq.org/MacOSX http://wiki.winehq.org/MacOSX/FAQs
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #20 from Austin English austinenglish@gmail.com 2009-06-23 10:53:28 --- (In reply to comment #19)
Invalid indeed to the purist. My suggestion is to nevertheless keep it open, so people can find it given good keywords: winevdm C:\windows\system32\winevdm.exe MacOS "page fault on read access to 0xffffffff" old 16bit application
While I normally agree with that, there's now a configure check, so packagers/people that compile will know it advance.
BTW, who is authorized to edit the completely misleading and outdated http://wiki.winehq.org/MacOSX http://wiki.winehq.org/MacOSX/FAQs
Anybody with a wiki account. Create one and edit away ;-).
http://bugs.winehq.org/show_bug.cgi?id=14920
jmm6820@rit.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #21 from jmm6820@rit.edu 2009-06-23 13:34:16 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #22 from Jörg Höhle hoehle@users.sourceforge.net 2009-06-24 05:08:16 --- Mike Kronenberg wrote in http://www.winehq.org/pipermail/wine-devel/2009-May/075813.html
Thats why my downloadable builds are all made on Tiger (XCode 2.x) to have a single app running on both systems.
Indeed his build of wine-1.1.21 works with the 16bit app I tried, while my build (Xcode 3.x) crashes in winevdm.
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #23 from Jörg Höhle hoehle@users.sourceforge.net 2009-06-24 08:40:20 --- Well, the linker (ld, dyld), assembler (as), otool etc. are available as source from http://www.opensource.apple.com/ after all, in package cctools: XCode version cctools xc2.5 622.9 cctools xc3.0+OS10.5 667.3 cctools xc3.1.3 698.1
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #24 from Austin English austinenglish@gmail.com 2009-06-24 10:54:55 --- Looks like AJ committed a workaround: http://source.winehq.org/git/wine.git/?a=commitdiff;h=691bdbd12396678ef25e34...
could you retest in git?
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #25 from Alexandre Julliard julliard@winehq.org 2009-06-24 14:51:29 --- (In reply to comment #24)
Looks like AJ committed a workaround: http://source.winehq.org/git/wine.git/?a=commitdiff;h=691bdbd12396678ef25e34...
could you retest in git?
This has nothing to do with this problem, it's a workaround for a different linker bug.
http://bugs.winehq.org/show_bug.cgi?id=14920
James McKenzie jjmckenzie51@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jjmckenzie51@earthlink.net
--- Comment #26 from James McKenzie jjmckenzie51@earthlink.net 2009-07-11 18:43:40 --- (In reply to comment #23)
Well, the linker (ld, dyld), assembler (as), otool etc. are available as source from http://www.opensource.apple.com/ after all, in package cctools: XCode version cctools xc2.5 622.9 cctools xc3.0+OS10.5 667.3 cctools xc3.1.3 698.1
@Joerg:
Have you been able to build XCode's 2.5 linker with XCode 3.1 'stuff' and get a successful build of Wine?
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #27 from Jörg Höhle hoehle@users.sourceforge.net 2009-07-13 02:20:24 --- Sorry, no. However I didn't try hard at all (nor try to understand what the different programs in the cctools archive do). I got too many compile errors that I did not investigate further. Among others, gcc was invoked with some unrecognized option; Perhaps the scripts are not prepared that I only installed gcc-4.2 on my system (not the default 4.0)?
Perhaps somebody who installed straight Xcode 3.x install would be successful? I merely installed individual packages like gcc4.2Leo, CoreAudioSDK, OpenGLSDK, X11User, DeveloperToolsCLI, DevSDK etc. A bug I need to send to Apple is that now, it won't let me install the whole Xcode meta package, as it says something like "can't install into a non-empty directory", without saying which one.
I also didn't cross-check whether I could build the version of cctools that corresponds to my DVD, rather than the old one.
http://bugs.winehq.org/show_bug.cgi?id=14920
Charles Davis cdavis@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cdavis@mines.edu
--- Comment #28 from Charles Davis cdavis@mines.edu 2009-07-25 17:54:27 --- (In reply to comment #23)
Well, the linker (ld, dyld), assembler (as), otool etc. are available as source from http://www.opensource.apple.com/ after all, in package cctools: XCode version cctools xc2.5 622.9 cctools xc3.0+OS10.5 667.3 cctools xc3.1.3 698.1
Wrong package. The package you want is the ld64 package. THAT is the Xcode 3.x linker, and THAT's the one with the linker bug. (Actually, it's available under Xcode 2.x as well, but it only became the default linker in Xcode 3.0. This, by the way, is the reason the package is called "ld64.")
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #29 from Charles Davis cdavis@mines.edu 2009-07-25 18:08:57 --- Created an attachment (id=22618) --> (http://bugs.winehq.org/attachment.cgi?id=22618) Patch to fix Apple linker bug
Here's a patch that fixes the linker bug. After you untar the ld64 package (it has to be ld64, NOT cctools), copy this file into the directory that was created (typically ld64-<version>), then from that directory do:
$ patch -p0 <ld64-16b-fix.patch $ xcodebuild ld64.xcodeproj
That will build a version of the linker with the linker bug fixed. If you then install the linker, and reconfigure Wine (with ./configure from the Wine source directory), it should work. (In particular, you need to make sure that the version in /usr/libexec/gcc/<gnu-platform-id>/<version> is the fixed one. <gnu-platform-id> will be something like i686-apple-darwin9.)
Short explanation: I had a hunch about what went wrong. I took AJ's example and added a third NOP. Instead of going to the wrong label, it went exactly two bytes away from the correct label. I then tracked the bug down to this line in src/MachOReaderRelocatable.hpp:
pointerValue = srcAddr + (int16_t)E::get16(*((uint16_t*)fixUpPtr)) + sizeof(uint16_t);
I changed it to this:
pointerValue = srcAddr + (int16_t)E::get16(*((uint16_t*)fixUpPtr)) + sizeof(uint32_t);
and now it works. Notice that the fixed version adds 4 bytes (the size of a uint32_t) instead of 2.
I encourage you to try this and see if this helps. (I really need to send this to Apple...)
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #30 from James McKenzie jjmckenzie51@earthlink.net 2009-07-25 20:09:56 --- (In reply to comment #29)
Created an attachment (id=22618)
--> (http://bugs.winehq.org/attachment.cgi?id=22618) [details]
Patch to fix Apple linker bug
Here's a patch that fixes the linker bug. After you untar the ld64 package (it has to be ld64, NOT cctools), copy this file into the directory that was created (typically ld64-<version>), then from that directory do:
Which version? I just downloaded the newest version. Will attempt to patch and build it.
James McKenzie
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #31 from James McKenzie jjmckenzie51@earthlink.net 2009-07-25 20:20:14 --- Patched successfully but build failed with:
xcodebuild ld64.xcodeproj === BUILDING NATIVE TARGET ld WITH THE DEFAULT CONFIGURATION (Release) ===
Checking Dependencies... unsupported build action 'ld64.xcodeproj' ** BUILD FAILED **
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #32 from Charles Davis cdavis@mines.edu 2009-07-25 20:25:53 --- (In reply to comment #31)
Patched successfully but build failed with:
xcodebuild ld64.xcodeproj === BUILDING NATIVE TARGET ld WITH THE DEFAULT CONFIGURATION (Release) ===
Checking Dependencies... unsupported build action 'ld64.xcodeproj' ** BUILD FAILED **
To answer you question about the version, I generated the patch against ld64 version 77.1 (the 10.5.7 version).
And that command line is obviously wrong (sorry, my bad; I didn't read the manpage before writing that post). It should be:
$ xcodebuild
from the ld64-77.1 directory, and it should build. (If you want to build some other configuration, try using the -configuration option. See xcodebuild(1) for more details.)
Or, you could just open the project file in Xcode, like this:
$ open ld64.xcodeproj
and then from the Xcode window, click the "Build" button in the toolbar. (Again, feel free to select a different configuration.)
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #33 from James McKenzie jjmckenzie51@earthlink.net 2009-07-25 20:49:02 --- (In reply to comment #32)
(In reply to comment #31)
Patched successfully but build failed with:
xcodebuild ld64.xcodeproj === BUILDING NATIVE TARGET ld WITH THE DEFAULT CONFIGURATION (Release) ===
Checking Dependencies... unsupported build action 'ld64.xcodeproj' ** BUILD FAILED **
To answer you question about the version, I generated the patch against ld64 version 77.1 (the 10.5.7 version).
The build states it is successful, but ld is a symlink to /bin/ld which did not get updated.
I'll look to see if it went somewhere else.
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #34 from Jeffrey Pfau archaemic.spam@gmail.com 2009-07-25 21:03:57 --- This seems to have worked for me. I built an old version of Wine (1.1.24) against it, and at least one 16-bit app launched, but it was a bit flaky. Mostly errors regarding FreeType not being found, but there was one other crash:
err:module:DelayLoadFailureHook failed to delay load setupapi.dll.InstallHinfSectionW wine: Call from 0x7b8320d7 to unimplemented function setupapi.dll.InstallHinfSectionW, aborting wine: Unimplemented function setupapi.dll.InstallHinfSectionW called at address 0x7b8320d7 (thread 000b), starting debugger...
Built it against the MacPorts version (1.1.26), but it seems there's a check in there now to prevent me from running 16-bit applications when I "can't".
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #35 from Charles Davis cdavis@mines.edu 2009-07-25 21:08:15 --- (In reply to comment #33)
(In reply to comment #32)
(In reply to comment #31)
Patched successfully but build failed with:
xcodebuild ld64.xcodeproj === BUILDING NATIVE TARGET ld WITH THE DEFAULT CONFIGURATION (Release) ===
Checking Dependencies... unsupported build action 'ld64.xcodeproj' ** BUILD FAILED **
To answer you question about the version, I generated the patch against ld64 version 77.1 (the 10.5.7 version).
The build states it is successful, but ld is a symlink to /bin/ld which did not get updated.
I'll look to see if it went somewhere else.
Ld was never installed at all. (Sorry if I misled you in my earlier post.) By default, xcodebuild only builds the targets; it does not install them. The file you're looking for is in build/Release in the ld64 project directory.
Or, you could type:
$ xcodebuild install -configuration Release
from the project directory, and that will install the Release build of the linker in /tmp/ld64.dst. If you look at that directory, you'll find that there's a directory called "usr" in it. And in that "usr" directory, you'll find a directory called "bin". In the bin directory is the linker "ld". (There's also an image rebaser tool, "rebase".)
If you then do:
$ sudo cp -R /tmp/ld64.dst /
then the linker will be installed in /usr/bin.
I should have put this information in my earlier post. Sorry about that.
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #36 from James McKenzie jjmckenzie51@earthlink.net 2009-07-26 15:16:10 --- This fixed the problems with crashes with BiblePro in Win16 Mutex, but the program still does not want to run properly. Different bug which I will file.
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #37 from Charles Davis cdavis@mines.edu 2009-07-26 15:53:26 --- Glad to hear my patch works for some people.
So, to summarize, this is (at least in part) a problem with the new Mac OS X linker, ld64. To fix the problem on your machine:
1. Go to www.opensource.apple.com. Click on your version of Mac OS X, and download the ld64 source tarball. 2. Untar the tarball. 3. Download my patch to the ld64 project directory that was in the tarball. 4. From that same directory, issue these commands to build and install a fixed version of the linker: $ patch -p0 <ld64-16b-fix.patch # Applies my fix $ xcodebuild # Builds ld64 $ xcodebuild install -configuration Release # Installs ld64 to /tmp/ld64.dst/usr/bin $ sudo cp -R /tmp/ld64.dst / # Installs ld64 to /usr/bin 5. Build and install Wine from source as usual.
You shouldn't have to pass the --disable-win16 switch to the configure script anymore with my ld64 patch. Avoid the MacPorts version if you want this support: it passes this option.
Perhaps I should add this to the Mac OS X FAQ...
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #38 from Charles Davis cdavis@mines.edu 2009-07-26 15:54:28 --- Glad to hear my patch works for some people.
So, to summarize, this is (at least in part) a problem with the new Mac OS X linker, ld64. To fix the problem on your machine:
1. Go to www.opensource.apple.com. Click on your version of Mac OS X, and download the ld64 source tarball. 2. Untar the tarball. 3. Download my patch to the ld64 project directory that was in the tarball. 4. From that same directory, issue these commands to build and install a fixed version of the linker: $ patch -p0 <ld64-16b-fix.patch # Applies my fix $ xcodebuild # Builds ld64 $ xcodebuild install -configuration Release # Installs ld64 to /tmp/ld64.dst/usr/bin $ sudo cp -R /tmp/ld64.dst / # Installs ld64 to /usr/bin 5. Build and install Wine from source as usual.
You shouldn't have to pass the --disable-win16 switch to the configure script anymore with my ld64 patch. Avoid the MacPorts version if you want this support: it passes this option.
Perhaps I should add this to the Mac OS X FAQ...
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #39 from Charles Davis cdavis@mines.edu 2009-07-26 22:42:09 --- (In reply to comment #38)
$ sudo cp -R /tmp/ld64.dst / # Installs ld64 to /usr/bin
Oops... this won't work. All it does is create a directory in root named ld64.dst. It's just that my experience with the `cp' command on Mac OS is that if the source is a directory and the -R option is passed, the contents of the directory get copied to the destination (instead of the directory itself); this happens when copying bundles, for example. Maybe it behaves differently with the root directory as a destination. In any case, I really, really, REALLY need to get in the habit of trying my solutions before posting them. Again, this is my bad, so don't blame yourself if you tried this and it doesn't work.
To really install ld64, you need to make a small modification to that command:
$ sudo cp -R /tmp/ld64.dst/* /
THAT will install everything into their proper locations.
http://bugs.winehq.org/show_bug.cgi?id=14920
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Win16 programs crash with |Win16 programs crash with |Wine built with newer XCode |Wine built with newer XCode |on Mac OS X |on Mac OS X (Not a Wine | |bug)
http://bugs.winehq.org/show_bug.cgi?id=14920
Saulius K. saulius2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |saulius2@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=14920
C.W. Betts computers57@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |computers57@hotmail.com
--- Comment #40 from C.W. Betts computers57@hotmail.com 2010-04-07 04:03:27 --- I do believe this is fixed in the latest Xcode build, and has been since at least Snow Leopard. Because win16 builds without comment on my system.
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #41 from James McKenzie jjmckenzie51@earthlink.net 2010-04-16 21:53:54 --- (In reply to comment #39)
(In reply to comment #38)
$ sudo cp -R /tmp/ld64.dst / # Installs ld64 to /usr/bin
Oops... this won't work. All it does is create a directory in root named ld64.dst. It's just that my experience with the `cp' command on Mac OS is that if the source is a directory and the -R option is passed, the contents of the directory get copied to the destination (instead of the directory itself); this happens when copying bundles, for example. Maybe it behaves differently with the root directory as a destination. In any case, I really, really, REALLY need to get in the habit of trying my solutions before posting them. Again, this is my bad, so don't blame yourself if you tried this and it doesn't work.
To really install ld64, you need to make a small modification to that command:
$ sudo cp -R /tmp/ld64.dst/* /
THAT will install everything into their proper locations.
Charles:
Does this problem still exist with XCode 3.1.3 (the latest download from Apple)?
I know that this was fixed in XCode 3.2, but it only works with Snow Leopard and I'm not ready to move to it yes (too many folks still playing with Leopard, even Tiger...)
James
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #42 from Charles Davis cdavis@mines.edu 2010-04-16 22:21:30 --- (In reply to comment #41)
Charles:
Does this problem still exist with XCode 3.1.3 (the latest download from Apple)?
Wouldn't know, I don't use Xcode 3.1 anymore. I upgraded to SL the moment it came out.
I guess I could try building the ld64 from 3.1.3 to see if that fixes it.
I know that this was fixed in XCode 3.2, but it only works with Snow Leopard and I'm not ready to move to it yes (too many folks still playing with Leopard, even Tiger...)
I know. A lot of people didn't (and still don't) consider SL worth the $39 ($29? Can't remember, it was a while ago) it costs to upgrade from Leopard. All the stuff that changed is mostly under the skin; you really don't notice it (except that the system is faster because the programs and the kernel became 64-bit).
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #43 from Charles Davis cdavis@mines.edu 2010-04-16 22:55:27 --- (In reply to comment #42)
(In reply to comment #41)
Charles:
Does this problem still exist with XCode 3.1.3 (the latest download from Apple)?
Wouldn't know, I don't use Xcode 3.1 anymore. I upgraded to SL the moment it came out.
I guess I could try building the ld64 from 3.1.3 to see if that fixes it.
Actually, 3.1.4 is the latest (for Leopard, anyway). And no, they still haven't fixed the linker bug.
You could try building ld64 95.2.12 (the version from Xcode 3.2).
http://bugs.winehq.org/show_bug.cgi?id=14920
Rex Tsai chihchun@kalug.linux.org.tw changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chihchun@kalug.linux.org.tw
http://bugs.winehq.org/show_bug.cgi?id=14920
mdt1124 younqbossmikeex5@aim.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |younqbossmikeex5@aim.com
http://bugs.winehq.org/show_bug.cgi?id=14920
--- Comment #44 from Jeffrey Pfau jeffrey.pfau@gmail.com 2011-07-11 12:32:06 CDT --- This appears to have been fixed a long time ago. I verified that Wine compiled with a vanilla version of ld64 in Xcode 3.2.4 works with a 16-bit version of SimTower, and I'm pretty sure it's been this way for a while.
http://bugs.winehq.org/show_bug.cgi?id=14920
John Musbach johnmusbach1@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #45 from John Musbach johnmusbach1@gmail.com 2011-07-15 17:05:47 CDT --- (In reply to comment #44)
This appears to have been fixed a long time ago. I verified that Wine compiled with a vanilla version of ld64 in Xcode 3.2.4 works with a 16-bit version of SimTower, and I'm pretty sure it's been this way for a while.
Yeah, I first reported this issue in '09. Things seem to have since been fixed so this can probably be marked as resolved instead of new. Though I'm always amazed how many things continue to trickle in related to this bug report. :)
http://bugs.winehq.org/show_bug.cgi?id=14920
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |INVALID
--- Comment #46 from Dmitry Timoshkov dmitry@baikal.ru 2011-07-16 01:50:19 CDT --- Not a Wine bug.
http://bugs.winehq.org/show_bug.cgi?id=14920
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #47 from Austin English austinenglish@gmail.com 2011-08-02 11:02:27 CDT --- Closing.
http://bugs.winehq.org/show_bug.cgi?id=14920
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Mac OS X 10.5 |Mac OS X
-
wine-bugs＠winehq.org