On Jan 8, 2015, at 10:11 PM, Ken Thomases ken@codeweavers.com wrote:
Hi,
I am attaching a new patch to get Wine building and running 64-bit on OS X. This now launches built-in programs like winecfg, etc. I have also run the MSI installers for SketchUp and 7-Zip; although they seemed to go through to completion, they didn't work completely correctly. (I'm not sure prefix creation was right, either.)
This is based on strooka's work at https://github.com/strook/wine-dev-x86_64/commit/5dd3cca2200cdf1b6fa5afb185e5086500df4130. (I started this before his subsequent commit and my work largely eliminates the need for that one.)
I have rebased onto current git tip (wine-1.7.33-191-ge899bd8). strooka's work was based on 1.7.8.
Funny you should mention that, since I have my own patches for Wine64 on Mac OS, which I’m now attaching to this email. It’s a bit less hacky than strooka’s (even if I do say so myself), in part because the __ms_va_list stuff isn’t defined away. I have rebased my patches onto Wine HEAD as of tonight.
Apple GCC won’t work for obvious reasons, so you need either vanilla GCC or Clang. I haven’t tested with FSF GCC, but if you use Clang, you need to build it yourself with some patches against LLVM and Clang that I wrote (and that I have also attached), but haven’t yet bothered upstreaming. Some of them fix nasty miscompiles when mixing System V and Win64 calling conventions, and others, of course, add support for __ms_va_list. They are, of course, against LLVM tip-of-tree.
Mine doesn’t seem to work correctly, either; there are some other issues that may or may not be related to Clang/LLVM miscompiles that I haven’t fixed yet. In particular, there were some pretty hairy issues with DWARF debug information that made symbolic debugging nigh impossible.
This is still a hack-and-slash job, although I have cleaned up some of strooka's work. In particular, the changes to dlls/ntdll/signal_x86_64.c are much simpler and cleaner.
Since it's a hack job, it will break builds for other platforms/architectures, including 32-bit Wine for OS X. As a consequence, you would have to maintain separate source bases to build a shared WoW64 setup. I haven't tried yet.
My patches do not have this problem ;). I had my eye on WoW64 from the start.
The configure line that strooka recommended had a lot of extraneous stuff. I configured with:
./configure --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib --enable-win64 --disable-wineqtdecoder --disable-win16
I thought --disable-win16 was implicit in --enable-win64. Also, one of my patches automatically disables wineqtdecoder if Wine64 is enabled.
The Mac driver crashes in a 64-bit build for reasons I haven't investigated, so you have to use the X11 driver.
Yipe! I think I recall having this problem myself.
Chip