Support of the next version of macOS

[qparis]

This is a memo to find a solution so that our wine builds work for 32bits programs in the next version of macOS.

It seems that there are no official solutions yet.
If have tried use this repository https://github.com/AndreRH/hangover. By tweaking a little bit their solution, I'm able to cross compile it but I'm unable to run binaries (A lot of DLLs are missing)

[plata]

What is "this repository" and "their solution"?

[qparis]

The link was omitted: https://github.com/AndreRH/hangover

Basically, the idea is to compile qemu and modified wine dlls thanks to winegcc.

[Gcenx]

Hangover is one of the solutions being worked on

The other is compiling wine using this version of clang to compile wine -mwine32
https://github.com/cdavis5e/clang/tree/wine32

[qparis]

How does it work?

[Gcenx]

How does it work?

Using that custom version of clang to compile wine using the -mwine33 flag will compile wine as 64Bit binary that supports 32Bit calls and trunking 32Bit to 64Bit.

He explains some of what’s he is doing in the commit notes

[qparis]

Waho! Does it work well?

[Gcenx]

Waho! Does it work well?

Honestly I’ve had no time to test it out myself, due to my job and cram course so zero time off.
But I know it’s constsntly being worked on and was the other option that was mentioned during the last wine conference.

This will work much better then hangover since it’s not emulation.
I wouldn’t be surprised if when we see the new FF ports he’s working on that uses DXVK also being built with this.

[qparis]

Ok, we need to test this :)

[qparis]

@Gcenx I tried to compile this clang version and it produces a binary that segault when it is run. I cannot find anything online to sort that out

[qparis]

Ok, I can compile simple files with with -mwine32 (see last commit).
However, as expected I am not able to compile wine. There probably are a lot of work adapting wine as well.

[Gcenx]

At least you get the patched clang working that's something, we could even use that for all macOS compiles since it already includes the needed ms_hook_prologue support.

I'm in class so I only got a quick look, I don't know why your setting target as x86_64, from my understanding it should be set as 32bit as usual but passing -mwine32 would do the trunking at compile time.

Side Note;
I need to pull in all the new commits to verify it against my offline version as I made some Environment changes to avoid some annoyances later. I will update my offline version before doing a pull-request.

[qparis]

At least you get the patched clang working that's something, we could even use that for all macOS compiles since it already includes the needed ms_hook_prologue support.

True

I'm in class so I only got a quick look, I don't know why your setting target as x86_64, from my understanding it should be set as 32bit as usual but passing -mwine32 would do the trunking at compile time.

Yeah this is not shown in the commit but that's what I did. When mwine32 is set, #ifdef x86_64 returns true and wine "thinks" that we are compiling for a 64bits target, which is obviously not what we want. There is a i386_on_x86_64 flag for this but I think it depends on the cases

Side Note;
I need to pull in all the new commits to verify it against my offline version as I made some Environment changes to avoid some annoyances later. I will update my offline version before doing a pull-request.

Thanks! Feel free :)

[qparis]

By the way, the patch I have uploaded is slightly modified from cdavis5e's one so that it is compatible with Debian llvm 7.0 package.
If it works as expected, it might interest the wine team to do so cross compilation task

[Gcenx]

By the way, the patch I have uploaded is slightly modified from cdavis5e's one so that it is compatible with Debian llvm 7.0 package.
If it works as expected, it might interest the wine team to do so cross compilation task

I’m assuming Winehq will just move to using the one from cdavis5e once it functions the way it’s intended, they already use a patch clang anyway.
Maybe this patched clang when finished fully could be compiled and uploaded to say OBS?

I need to do some more tests to confirm everything is still working fine, but I propose dropping the older environment in favor of the newer one, I’ve also gutted multi-lib since it won’t be needed with my changes.

I did a quick look for a hangover builder but I don’t see a script?
I wanted to also test that against the new environment, since it’s possible to use a single Environment for all Darwin builders

[Gcenx]

@qparis I’m just checking be did you also include the patches from llvm?

Also could you upload your handover builder/items into another branch so I can look over them I want to try getting that working also as a fallback

[qparis]

I think I did.
Concerning hangover, I do not have anything else so far.. I haven't retried recently thought

[Gcenx]

I think I did.
Concerning hangover, I do not have anything else so far.. I haven't retried recently thought

Just wanted to be sure on that one.

Yeah I didn’t really try hangover myself yet, I just made small changes to reflect the part I did read over.

[qparis]

@Gcenx I have succesfully run a 32bits hello world program on wine64 thanks to hangover

[qparis]

And ... also notepad++

[qparis]

https://repository.playonlinux.com/hangover.zip

[qparis]

Here is our first 32bits compatible build that runs on macOS 64bits:
https://www.playonlinux.com/wine/binaries/phoenicis/hangover-darwin-amd64/PlayOnLinux-wine-4.0-hangover-darwin-amd64.tar.gz

Of course, many many many programs won't run, but still promising

[qparis]

@Gcenx In fact -mwine32 leads to a Segfault (11) with our current build (even with a small program). I don't know if I have missed something.
However, wine can build

[Gcenx]

@qparis I'm sure were still missing something but since regular wine builds I guess we should leave this alone until macOS Catalina is released/CrossOver version for it is released.

[Gcenx]

@qparis I’ve been really busy as of late, but I got around to trying to test out hangover myself this time but the environment is failing at

phoenicis-winebuild/environments/linux-amd64-wine_osxcross_hangover

Line 47 in 30ee32b

WORKDIR /root/hangover/build/libxslt64

Since I can’t build for what ever reason I checked over the builder and noticed something strange, wine-host is set to install into

phoenicis-winebuild/builders/scripts/builder_darwin_amd64_wine_hangover

Line 41 in 30ee32b

make install DESTDIR="/root/wine"

But later we reference the unused location --sysroot=/root/hangover/build/wine-host/

phoenicis-winebuild/builders/scripts/builder_darwin_amd64_wine_hangover

Line 109 in 30ee32b

/root/hangover/build/wine-tools/tools/winegcc/winegcc -b x86_64-apple-darwin15 -B/root/hangover/build/wine-tools/tools/winebuild/ -I/root/hangover/build/wine-host/include/ -I/root/hangover/wine/include --sysroot=/root/hangover/build/wine-host/ "\$@"

I’m guessing a symlink would cover the above.

[ImperatorS79]

We could rename this issue "Support OSes with no 32 bits libs", since ubuntu will drop 32 bits libs too. The 32 bits to 64 bits trunking seems the best option but it does not seem to have been updated for a while. Might be worth asking wine devs as @plata suggested in PhoenicisOrg/phoenicis#2012

[qparis]

@ImperatorS79, maybe yes. However, the solution may be different on Ubuntu since that they will probably still let the kernel execute 32bits software, contrary to macOS.

@Gcenx, the first problem is weird. The command is just « workdir », it should work.

Concerning your remark, /root/wine contains the built binary, which we’ll be extracted from the docker context. /root/hangover/build/wine-host contains the build objects which is a bit different

[Gcenx]

@qparis yeah I’m guessing it failed on the next line where that was the last working one.
I thought the version of wine we compiled was used by --sysroot=

mkdir -p /root/hangover/build/wine-host cd /root/hangover/build/wine-host export C_INCLUDE_PATH="/root/osxcross/target/macports/pkgs/opt/local/include/:/root/osxcross/target/macports/pkgs/opt/local/include/libxml2/:/root/vkd3d/include/" export LIBRARY_PATH="/root/osxcross/target/macports/pkgs/opt/local/lib" ../../wine/configure --enable-win64 --host x86_64-apple-darwin15 --prefix="/" --with-wine-tools="/root/hangover/build/wine-tools" LFFLAGS=" -Wl,-rpath,/opt/x11/lib -L/root/osxcross/target/macports/pkgs/opt/local/lib -F/root/osxcross/target/macports/pkgs/opt/local/Library/Frameworks" make -j4 make install DESTDIR="/root/wine" touch /root/hangover/build/wine-host/.built

Seems I didn’t follow so we’re using the build folder instead of the install, but couldn’t that cause issues over using the install?

@ImperatorS79 I would avoid using hangover for Linux as @qparis said unless they block executing 32Bit code drastic measures like Hangover shouldn’t be needed. I’m sure Valve will also be contacting them about this not just CodeWeavers.

[ImperatorS79]

I did not talk about hangover ^^. But, since in the future every distro with certainly drop building 32 bits libs (which will not be downloadable from older distro due to too old versions), I am sure wine will have to come up with something

[Gcenx]

@ImperatorS79 good as Hangover feels like dead end to me outside of arm64.
I’m starting to think to current push to compile PE files for everything within Wine is related to the coming removal for 32Bit libs from Linux not just macOS.

As what’s stopping mingw cross-compiling 32Bit Windows dll files with 64Bit libs on Linux? Only blocker I can see is Wine being 32Bit, that’s lightly what ccdavis was working on the custom clang for trunking 32Bit to 64Bit

[Gcenx]

To compile wine32on64 you must use the custom llvm/clang-8 or it won’t properly compile.

You also need to use the disables I've posted that @qparis embedded into the script or it will end up just failing

Even with the disables and the patched source from here or my own repository there will still be warnings when building but most can just be ignored.

[qparis]

Right now we have two main tasks to achieve:

• try to figure out how to avoid SIP
• apply the win32on64 diff on current wine. I’ve started this task

[Gcenx]

SIP is the major annoyance here

Getting the winetools/winegcc/winebuild changes onto upstream wine was easy, the rest is more of a pain as you need to avoid patching items that are PE format in current upstream.

Unfortunately some PE format items were reverted to ELF for CrossOver19 due to anti-virus false positives, I’d say reverting these back to being PE format again should help getting a viable patch set to apply onto upstream wine

[HarukaMa]

@Gcenx I was using modified llvm/clang from crossover sources and built it like normal llvm toolchains, and used wine source code from your repo winecx and built it like normal WoW64 builds, with wine32on64 configurations

CC=/Users/MrX/src/crossover/llvm/bin/clang-8 CXX=/Users/MrX/src/crossover/llvm/bin/clang++ CPP=/Users/MrX/src/crossover/llvm/bin/clang-cpp ../configure --enable-win32on64 --with-wine64=../wine64 --disable-winedbg --without-x --without-vulkan --without-vkd3d --without-gphoto --without-cms --without-gsm --without-gstreamer --disable-tests

It still gives lots of "changes address space of pointer" errors:

In file included from ../../../dlls/acledit/main.c:28:
../../../include/wine/debug.h:196:40: error: passing 'const char * __ptr64 __storage32' to parameter of type 'const __storage32 char *' changes address space of pointer
    vsnprintf( buffer, sizeof(buffer), format, args );
                                       ^~~~~~
../../../include/msvcrt/stdio.h:302:68: note: passing argument to parameter 'format' here
static inline int vsnprintf(char *buffer, size_t size, const char *format, __ms_va_list args) { return _vsnprintf(buffer,size,format,args); }
                                                                   ^

I now think that maybe I was not using correct build options for llvm/clang, but can't figure out what I was missing there.

It seems that the scripts of this repository is meant for cross-building on Linux, but I'm building it directly from Catalina. Could this be the reason?

[qparis]

@HarukaMa Try to install Docker on Mac, the scripts will then work out of the box

[HarukaMa]

The issue is I'd like to tinker with the wine source code as I was trying to make a specific software install without error. Scripted builds within containers sounds troublesome when I need to frequently edit the wine source code...

[qparis]

You can if you create a distribution targeting a custom git repository or a local file.
We could even improve the scripts so we can resume compilations

[Gcenx]

@HarukaMa I'll run a clean build on Catalina and check the build log and get back to you but I've been able to build on Mojave and Catalina.
Did you use make -k ? as that will allow the build to continue even with some build errors

Also managed to cross-build wine on Catalina for 10.8 just needed to disable 16Bit mode that's how I've built the wine-crossover that I'd added to my homebrew tap.

[Gcenx]

@HarukaMa completed a wine32on64 only build and I don't have that error so I'm not sure what's wrong on your end

I have the following packages installed via brew;

bison		freetype	jpeg		mingw-w64	pkg-config
cabextract	gettext		libmpc		mpfr		sdl2
faudio		gmp		libpng		mpg123		unrar
flex		isl		libtiff		p7zip		winetricks

bison, flex & gettext need to be manually added to PATH as those are celler only when using brew, I usually use macports but I wanted to experiment with using brew for this.
Other dependencies are missing like gnutls but these are a nice base to get started

[HarukaMa]

I've completely forget that now many executables are compiled to PE format, and I was missing mingw-w64. It seems that after installing it the compilation is running good (still running right now but already passed dlls which were failing).

Thanks for the tip!

[Gcenx]

Yeah mingw is a hard requirement now as half the PE files just won't compile correctly using clang due to upstream bugs, I had partly update the Winehq macOS/Building Wiki section to include mingw-w64 for homebrew section.

But not the macports section yet due to mingw-w64 currently failing to build on Catalina.

[Gcenx]

@qparis since this now builds I’ll update WineCX to 19.0.1.

[HarukaMa]

It seems that on macOS, compilation is good enough but the linker somewhat messed up and all 32-bit .so files are not loadable:

0009:err:module:load_so_dll failed to load .so lib "/usr/local/lib32on64/wine/winecfg.exe.so": dlopen(/usr/local/lib32on64/wine/winecfg.exe.so, 258): malformed rebase opcodes (467/504): address 0x6B98C7D4 is outside of segment __DATA_CONST (0x6B946000 -> 0x6B947000) in /usr/local/lib32on64/wine/winecfg.exe.so

I'm not able to use LLD on macOS as it's currently broken on frameworks. Gonna try the docker build script...

[Gcenx]

Oh that issue, you can actually resolve that one of two ways.

You can set

MACOSX_DEPLOYMENT_TARGET=10.14

Or alternately use SDKROOT

Xcode11/10.15SDK has some weirdness

[Gcenx]

@qparis I’ve had time over the weekend to update my “Darwin simplification” branch so it matches head.

• updated self built libraries
• ncurses strip patch added
• sdl2 2.0.12 patched to work correctly (macOS bug)
• gcc wrappers added (use our patched clang-8 with settings pre applied)
• pkgconfig wrappers added (osxcross wrappers have issues)
• cmake wrapper patched (uses custom wrappers instead of osxcross)

The Darwin environment and all scripts were cleaned up considerably, examples were also updated accordingly.

The only question is what to do with the mac32/mac64 scripts I have them updated to build macOS Catalina only compatible builds, or should I just drop them in favor of the current merged implementation?

[Gcenx]

Apple made an interesting change with macOS Catalina 10.15.4.

Setting the boot argument no32exec=0 allows access to i386_set_ldt meaning wine32on64 will now function without needing to have SIP disabled on a users system.

A single reboot to recovery mode and running the following command in terminal

nvram boot-args=“no32exec=0”

[qparis]

I think it is still too complex... How does crossover managd to avoid this?

[Gcenx]

All there binaries are code-signed and notarized fully also with some entitlements.

[qparis]

This is not sufficient enough. I have try to sign and notarize and it did not work

[Gcenx]

Hum I wonder what's missing then as that should be what's required, I've recently seen an explosion of new Catalina users so the above while not ideal is something.

Did you get the read the other comment about "Darwin Simplification"?

[qparis]

Yep, if mac32 and mac64 are no longer required, they can be deleted. If your branch is able to build macOS builds properly, I guess we can merge it :)

[Gcenx]

I pushed it as a separate branch for the moment, I did a couple of test builds with it.

[Gcenx]

I’d forgotten to post here, I’d downloaded macOS Big Sur beta onto my Mac and wine32on64 is still functional.

[zhoub]

Sorry I still had the similar issue from compiler with whatever environment variables MACOSX_DEPLOYMENT_TARGET or SDKROOT when I tries to build from Catalina, with customized toolchain (clang8+llvm), it always reports the error at asm from C code, so strange.

[Gcenx]

@zhoub unless you need to apply some custom patches onto the CX sources there’s not much point compiling it from source yourself as there’s now multiple prebuilt packages available.

[Gcenx]

Closing this as for Intel/M series systems using rosetta2 we’ve long had a functional wine distribution that’s being used for the affected systems.

If hangover is ever needed that should be it’s own issue.