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 https://github.com/PhoenicisOrg/phoenicis-winebuild/blob/30ee32b7819c2640066fbf1acd88f27054b59091/environments/linux-amd64-wine_osxcross_hangover#L47

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 https://github.com/PhoenicisOrg/phoenicis-winebuild/blob/30ee32b7819c2640066fbf1acd88f27054b59091/builders/scripts/builder_darwin_amd64_wine_hangover#L41

But later we reference the unused location --sysroot=/root/hangover/build/wine-host/ https://github.com/PhoenicisOrg/phoenicis-winebuild/blob/30ee32b7819c2640066fbf1acd88f27054b59091/builders/scripts/builder_darwin_amd64_wine_hangover#L109

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 https://github.com/PhoenicisOrg/phoenicis/issues/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

[ImperatorS79]

Yes I was talking about ccdavis ' works, which, I hope, will go on thanks to/because of the new ubuntu announcement.

[Gcenx]

I don’t see us getting any solid information until the CrossOver version that fully supports the new version of macOS plus the FF port that’s also being worked on that’s using DXVK

[qparis]

@Gcenx What happens when you run the command manually on the container?

[Gcenx]

@qparis Honestly not had chance to check that yet, I’ll hopefully get chance Sunday

[Gcenx]

@qparis & @ImperatorS79 well we have some official word now on Catalina support via CrossOver19 at least

[qparis]

Not good news I guess

[Gcenx]

Honestly it’s not bad news, it’s just taking them a while. We might get to see something at wineconf if we’re lucky

If not at least we still know it’s still being worked on that’s better then nothing.

[Gcenx]

Seems we’re slowly getting closer to CrossOver19

I’m thinking the mac32/mac64 builders need to be altered to using a different environment that only installs 64Bit packages from macports, now all the required packages should already be available.

Only thing on source release will be checking if clang/llvm changed since @qparis built it.

I’m hoping to have an updated MoltenVk port accepted by macports before CrossOver19 source is uploaded. FAudio was already added but all new packages these days are only built as 64Bit.

[Gcenx]

CrossOver 19 Beta1 emails went out yesterday so we’re getting closer to a full release.

I didn’t check if I’m allowed to post results so I won’t be posting any for the moment.

[Gcenx]

@qparis CrossOver19 had officially been released and the source is already available for download

[qparis]

Awesome! Do you know if it works out of the box?

[Gcenx]

I’m at work currently so I can’t really tell you. But we will be needing a fully functional compile of the custom llvm/clang to build this.

I’m also rather sure this will require 4 compiles;

• winetools
• wine is a normal 32Bit compile
• wine64 a normal 64Bit compile
• wine32on64 would be our -mwine32 compile.

What’s interesting is wine32on64 in CrossOver19 anyway uses /wine, /wine64 and /wine32on64 contents. /wine for the 32Bit PE files, /wine64 was more for the dylibs and finally /wine32on64 for the trunked files.

Edit; Did a normal wow64 compile last night that completed without issue.

Edit2; On Sunday I’d build the custom llvm/clang on macOS and proceed to start working on getting wine32on64 compiled. No luck yet, seems I’ll need to disable some features to get it functional, I’m hoping my build from this morning December 16th 2019 completes.

[Gcenx]

@qparis I’d forgotten to post an update on this but I’ve build CrossOver19’s wine32on64 and it works on macOS Catalina!

So might wanna look over the custom llvm/clang-8 included within the CrossOver19 source, it would be preferable if that compiler could be used for everything.

They can also be combined into a single Engine;

• wine & wine-preloader (32Bit versions)
• wine32on64 & wine32on64-preloader
• wine64 & wine64-preloader Currently testing shrinking the file size slightly by symlinking all .exe and .dll files from /lib/wine into /lib32on64/wine

[qparis]

You are amazing! Would you be able to update winebuilds accordingly?

[Gcenx]

@qparis yeah I can update it, just need the llvm/clan-8 built with ld etc or it wont build.

[qparis]

So you want me to create an environment with it?

[Gcenx]

Could you compile the newer llvm/clang source included with CrossOver19 but add in ld etc so it can be used as the primary compiler within the environment.

Like previously were you provided prebuilt deb files to install clang-7?

[qparis]

Ok I will try

[qparis]

@Gcenx Can you update the codeweavers repository to add winecx 19? Can we isolate the patch that helps supporting 32on64?

[Gcenx]

@qparis yeah I’ll commit that later today alongside with the two usual patches and an additional one I needed to get it to compile.

We can try figuring out the patches is the members chat private?

[qparis]

I guess yes. I'm trying to build clang properly but it's not easy task. I'll maybe come up with a first attempt by the end of the day