nope
How are you building it? Independently from source?
Yeah. Going through the straight up git clone and working my way through, using ldd to try and find / patch in missing stuff with yay. Reminds me of when I built wayfire. That was a nightmare
it just finished. Excuse me while I see if my system self-destructs
Ok. Be mindful that files placed in the system this way won’t be tracked by the Arch package management system. That can have consequences down the line. It makes it hard to clean-up after these things as there’s nothing tracking their installation, but may also result in “file exists” errors when Arch/AUR packages attempt to write to the same location.
Using the Arch packages is akin to pkg under FreeBSD. Building from source with AUR packages, kinda similar to FreeBSD’s ports/, with the exception that Arch -git packages pull from the latest commit, not a specific release like FreeBSD ports.
I’ve been using FreeBSD for servers for the last couple decades. I know next to nothing about FreeBSD desktop, but I’m rather familiar with for server use.
The power of Arch is that you can build your own package install recipe (PKGBUILD) and it’ll be tracked by the system. The process you used now to build from source, can be inserted into a PKGBUILD file. That’s why you might simply reference the existing wine-git PKGBUILD file, at the very least as a guide.
I’ve yet to see if it will do anything
EDIT - created a wine prefix, downloaded mono, ran the game "Empire Earth’ 's installer, then failed spectacularly when I launched the game. It ran faster than I could keep up with, but with my launch bar (xfce) was overlayed on the screen.
I’m a bit burnt on the project but I will try your suggestion tomorrow. And LOL - I had to install tcsh shell to run the installer (cause f the parenthesese in the installer’s file name). Still did more than I expected.
EDIT 2- TES Oblivion worked perfectly on my cobbled together mess. Audio,overlays,everything. I’m gonna start over tomorrow and go for a proper PKGBUILD setup.
Did a fresh install of FreeBSD 14.3-p7 (latest branch, not quarterly). Got xfce up and running and the binary pkg of wine-devel updated and synced properly (32 and 64 bit matching versions)
Everything worked and the screaming speed was there.
I used the fuse driver to mount a flash drive and copied the port directory over. certainly was interesting.
in the configure part of the Makefile they specified without for almost all the options, then used a sed line to patch in the bsd code.
I’m thinking I could do something similar using wine-git as a base PKGBUILD container as was suggested..
Here are some interesting bits from the Makefile:
# Only devel/llvm17 and later come with necessary include files - PR274542
USES= bison cpe desktop-file-utils gmake \
llvm:min=17,build,noexport localbase \
pkgconfig sdl shebangfix tar:xz
And there are exclusions for most options, with the exception of 2 big ones:
--with-mingw CROSSCC="clang" \
--with-sdl \
So I’m thinking that the right mesa,version, mingw,and sdl libraries are a good place to start. If this info sparks ideas from anyone I’d love to know about it.
A fresh install, but you weren’t game to try the recently released FreeBSD 15.0? I was pencilling in some time to try it on one of my servers 
FreeBSD 15 is still a nightmare. Last I checked it (4 days ago) it still is largely broken for desktop use. Gaming in BSD is a bit of a niche and, as one would assume, not a priority right now. It’s up to 15.0-p1, and it’s fast as hell, but the drm-66-kmod is, to the best of my knowledge, still broken. For my card I have to use drm-61-kmod.
off topic…It’s a hobby of mine to push the resources of old computers, and there’s nothing better than a little bit 'o BSD for that. Inherited a n ancient i586 linux server running kernel 2.x . After getting past the outdated SELinux stuff I had a 90’s version of GNOME running. And yesterday I made an old cash register terminal sit up and beg by adding an externel nvme and pxe booting. But then I overvolted it and a capacitor on the board exploded. Literally. Was fun while it lasted.
EDIT: Google says this:
Multi-Arch in Wine: Newer Wine versions have built-in multi-arch support (WoW64), which might simplify things in the future, but isn’t fully integrated yet in FreeBSD ports.
Success. I was making it harder on myself than needed. This is all you need to do:
- fetch wine-git out of the AUR
- Open the PKGBUILD
- Change the pkgver variable by substitution of rc(x) to rc4
- run updpkgsums
- iun 'makepkg -si
That’s it. Build time was about 15 minutes, and everything works.
EDIT: oh right, you have t reboot before the wine program loader will work
A couple of notes here.
I don’t think changing the pkgver variable on a -git package does anything.
When you run makepkg on that package, it’ll pull the latest source from the git repository, and automatically update the pkgver variable in your PKGBUILD file to the version you just pulled (referencing the pkgver() method for how to structure that). Give it a go I noted this here.
Running updpkgsums shouldn’t change anything, because the only part of the source that’s changing (what’s pulled via git), SKIP’s the checksum.
source=('git+https://gitlab.winehq.org/wine/wine.git'
'30-win32-aliases.conf'
'wine-binfmt.conf')
sha256sums=('SKIP'
'9901a5ee619f24662b241672a7358364617227937d5f6d3126f70528ee5111e7'
'6dfdefec305024ca11f35ad7536565f5551f09119dda2028f194aee8f77077a4')
The real solution here, is running:
yay -S wine-git
Because that’s in practice, the same thing, just simpler.
-git PKGBUILDS pull the most recent versions in of the main git branch from the source, you can read it in the PKGBUILD as well as,@BlinkBlink already shared the important parts. So there’s no need to to change the PKGBUILD unless the it fails building for some reason.
In addition to that, as the wine project is actually in code freeze during the period of the release candidate development cycle, they are focusing on bug fixes solely. Therefore I wouldn’t expect major performance differences in between the individual rc revisions. The most recent rc4 might be more stable then rc2. But this is still a release candidate and not a stable release. And I guess it won’t take much longer until version 11.0 would be published as a stable release.
Marked the solution above, though the real solution is to be patient and wait for wine 11 stable to come out.