Implement GitHub Actions to build binaries

[SveSop]

Creating this issue here to remind us to create a GitHub action to automagically build binaries when that time comes.

I understood it on @Saancreed that it was some build issues on Ubuntu, so we probably should look into building this with Arch (as this seems to build just fine in Docker when i build manually).

[PetitMote]

I’d love to try to fix it, might learn a few things :slightly_smiling_face: How can I do that?

[Saancreed]

I made another attempt at using Ubuntu as prepared by GH Actions and here are my findings so far:

1. Actions' Ubuntu image fails to install 32–bit Wine because its multilib setup is completely broken at the moment. There exist some workarounds but all extremaly hackish in nature. Of course, the standard ubuntu:20.04 image from Dockerhub has no such issues.
2. WineHQ packages for Ubuntu are split in a way that makes it impossible to install winegcc without installing 32–bit Wine. Maybe we could force apt to ignore dependency on wine-devel-i386 but I don't know apt well enough to try it.
3. Canonical's Wine packages do allow us to install dev tools without 32–bit Wine and I could actually build wine-nvoptix once, but then after rebasing on top of current working-version branch it broke again, possibly because @SveSop updated some headers and Canonical's Wine package is only version 5.5, which is about as old as Ubuntu 20.04 itself.
4. Defs and fakedlls are installed to some strange locations. We should probably fix it.
5. Using archlinux container just works™ and gives easy access to up to date Meson and Wine. Side note but I completely don't understand people claiming that Ubuntu is somehow easier to use than Arch. If anyone comes who wanted to use a build from Arch CI on their Ubuntu machine I will be tempted to just tell them to build it on their own machine.

[jp7677]

Alternatively you could also consider this github action https://github.com/Joshua-Ashton/arch-mingw-github-action , it also contains wine. I'm using this here: https://github.com/jp7677/dxvk-nvapi/blob/master/.github/workflows/artifacts.yml#L25

[Saancreed]

There's no need, that action bundles the entire mingw-w64 package which is useless for us unless we migrate to separate unixlib (and fakedll would be replaced with actual PE binary for which we would need mingw).

[jp7677]

Yeah, correct, there is indeed far more in that container than you'll need, its charm is though that it is already a github action, so less code would be needed in the workflow action in this repository. But yeah, indeed a bit overkill ;)

[SveSop]

There is no need for 32-bit wine, but i guess it might be hard to ONLY install wine-64 dev package the way ubuntu deb system links them together? And well.. it IS doable on a live system and in docker, but it is rather hackish to do these days.

And building with wine-5.5 i think is way too old with the massive changes that has happened with wine-6.x last months. I do not know this "CI" build thingy enough to figure out how you set up packages, but i could do some investigations and figure out if i understand how it is set up (script-wise i mean).

[Saancreed]

There is no need for 32-bit wine, but i guess it might be hard to ONLY install wine-64 dev package the way ubuntu deb system links them together?

Actually, I think it would be possible with Canonical's packages for Ubuntu (but those are far too, uh, stable, for our needs), but it's not possible with WineHQ builds or Arch packages.

I do not know this "CI" build thingy enough to figure out how you set up packages, but i could do some investigations and figure out if i understand how it is set up (script-wise i mean).

Right now I just fetch the latest archlinux:base-devel tag from Dockerhub, enable multilib repo, update all packages and install meson, ninja and wine, the last of which has winegcc we need. Not as slim as Ubuntu could be when wine pull in a lot of dependencies, both 64–bit and 32–bit, but stupidly simple to set up. Then I just use meson and ninja as usual.

[SveSop]

How do you choose what to put in the archive finished? No fake-dll's or installscript there, just the libs..

nm.. i saw the yaml file.. it basically IS the "script", so commands needs to be added there i guess

[Saancreed]

The step just finds all files matching the usr/lib*/** glob but fakedlls are not installed into usr/lib* so they are ignored. We should provide correct install location for them in meson.build to fix this.

Install script can be added as another glob, but from a quick glance it doesn't look correct to me (like, why are we even setting DllOverrides? And why to native and not builtin?).

[jp7677]

About 32bits, optix is as far as I read since a long time x64 only, so you could consider dropping 32bit altogether. Additionally, if the Linux nvidia driver only has x64 optix in it (which I would assume, currently not behind my machine), 32bits wine-optix won’t work anyway.

[SveSop]

The step just finds all files matching the usr/lib*/** glob but fakedlls are not installed into usr/lib* so they are ignored. We should provide correct install location for them in meson.build to fix this.

Install script can be added as another glob, but from a quick glance it doesn't look correct to me (like, why are we even setting DllOverrides? And why to native and not builtin?).

I guess out of old habit, and mostly because i just copied the script from my nvlibs project :smile: Since nvoptix.dll does not exist in wine, it seems to load without any overrides, but if you replace a wine-provided .dll/fake.dll it is more of a guess... especially if you try to replace a .so lib with a pe .dll, since that may confuse wine a bit, and you would not know for sure if you are loading the built-in one or the linked-from-fakedll one from wine.

Could probably drop generating the fakedlls at all really, since there is little to no chance for it to be included in wine, and there should be no reason for any apps to check the dll version instead of calling the lib for a version check? Low chance i think...

@jp7677 Yeah, there is no such thing as 32-bit optix

[SveSop]

Debian does not have a wine package maintainer atm, and has not for a long time. That is the main reason nothing later than 5.x packages has been built using the debian/ubuntu package system. WineHQ builds the packages on OBS, so that is the main reason the packages are "weird".. cos they are built as 2 separate packages rather than as 1 package (well.. it is multiple packages - but split in 2 by _i386 and _amd64). It has mostly to do with poor multilib support when building wine, and even tho it was ok for a long while with 18.04 and 20.04, wine-6.23 i think added dependency on samba-dev, and smack - broken multilib again :cry:

I build my Ubuntu packages with docker so i dont have to force-install every time i switch, but it kinda sux to do it.. I have quite a bit of backstory of this crap, so if you want to know why i can probably try to explain... I can try fiddle a bit with docker and see if i can come up with a minimal build for it. Seems as the commands run in the yaml file is somewhat similar to the Dockerfile right?

[Saancreed]

About 32bits, optix is as far as I read since a long time x64 only, so you could consider dropping 32bit altogether. Additionally, if the Linux nvidia driver only has x64 optix in it (which I would assume, currently not behind my machine), 32bits wine-optix won’t work anyway.

Yeah, there is no such thing as 32-bit optix

Oh, derp, I should have paid more attention :sweat_smile: You guys are right, we should remove 32–bit.

Since nvoptix.dll does not exist in wine, it seems to load without any overrides, but if you replace a wine-provided .dll/fake.dll it is more of a guess... especially if you try to replace a .so lib with a pe .dll, since that may confuse wine a bit, and you would not know for sure if you are loading the built-in one or the linked-from-fakedll one from wine.

As far as I know, for Wine native means an actual PE, setting this for our nvoptix (or my nvml) would most likely cause our winegcc–produced ELF to be skipped when searching for it.

Could probably drop generating the fakedlls at all really, since there is little to no chance for it to be included in wine, and there should be no reason for any apps to check the dll version instead of calling the lib for a version check? Low chance i think...

True, but otoh if we leave it, we can install it into directory with Wine's other libraries which would cause Wine to automatically install it into every prefix it creates, which is very convenient. My PKGBUILD for wine-nvml does exactly that (also see Global Installation section in README).

I build my Ubuntu packages with docker so i dont have to force-install every time i switch, but it kinda sux to do it.. I have quite a bit of backstory of this crap, so if you want to know why i can probably try to explain... I can try fiddle a bit with docker and see if i can come up with a minimal build for it. Seems as the commands run in the yaml file is somewhat similar to the Dockerfile right?

I'll try to rework our CI workflow sometime today to remove 32–bit and probably also switch back to Ubuntu 20.04, this time using Canonical's image from Dockerhub and not this GH monster.

[SveSop]

I build nvml together with my custom wine-staging build, so it is automatically installed using fakedll's and ELF libs like nvcuda and whatever does. Works rather nice, and i think it would work fine with nvoptix aswell.. Just need to figure out how to not build for 32-bit target, but that should be no problem, so keeping the setup for fakedlls is nice..

Where is the license boundries drawn? I think there is a great deal of snippits in wine from eg. cuda.h headers for instance, yet it is still GPL licensed. Maybe i am reading too much into this "SDK License" thing in general? :smile: (I mean, we are NOT redistributing the SDK headers, as the headers we provide cannot be used to compile anything else that THIS project as it is...)

[SveSop]

Seems we pretty much reach a preliminary goal of setting up CI actions to generate binaries, so going to close this issue as solved, and we work on improving build/scripts later :+1: