Arch Linux

Oh duh, I forgot to remove the line that calls patch when I removed a patch. I fixed it now. Thanks.

1.1.38 doesn't compile here

patching file dlls/ntdll/file.c
Hunk #1 succeeded at 589 (offset 18 lines).
Hunk #2 succeeded at 653 (offset 18 lines).
[...]
Hunk #19 succeeded at 1152 (offset 18 lines).
Hunk #20 succeeded at 1168 (offset 18 lines).
patch: **** Can't open patch file ../libpng14.patch : No such file or directory

Unrelated to the most recent posts, but consider using wine-stable-wc that I just uploaded: http://aur.archlinux.org/packages.php?ID=33231. It is wine 9.45 patched to compile with the most recent libraries. Warcraft works perfectly with 9.45.

I decided to do this because there is a regression in the newest wine that causes the game to freeze (or lag) for a couple of seconds every few minutes. This bug is on the AppDB so hopefully it will be figured out soon. Until then, I would suggest using the aforementioned package.

Try adding PKG_CONFIG_LIBDIR=/usr/lib32/pkgconfig when running configure. It uses pkg-config which by default will look in /usr/lib/pkgconfig which is only for the 64-bit libraries I presume. The installed 32-bit libraries install their own pkg-config files into the appropriate place (probably /usr/lib32/pkgconfig).

PKG_CONFIG_LIBDIR=/usr/lib32/pkgconfig ./configure

It seems that the reason why is that Arch is basically incapable of compiling 32-bit packages from a 64-bit platform, since Arch's gcc package doesn't support "multilib", gcc's cross-compiling support. There is a package here on AUR for GCC with cross-compiling support enabled ("gcc-multilib"), but even with that package in place I can't seem to get the package to compile. It complains about missing 32-bit libraries (saying that gcc -lgnutls fails, as well as gcc -lfreetype). I can't figure out how to resolve the library path issues because I'm not familiar enough with GCC configuration, but it makes no difference on my machine whether or not the libraries in question exist in /usr/lib32.

Setting LDFLAGS="$LDFLAGS -L/lib32 -L/usr/lib32" and LIBRARY_PATH="$LIBRARY_PATH:/lib32:/usr/lib32" in the BUILDPKG also seems to do nothing.

I'm currently in the process of compiling your package in a 32-bit chroot so I can get a binary and replace the one from the vanilla bin32-wine BUILDPKG with it. I'll let you know how it goes, and I'd appreciate any insight into the library path/gcc issues.

I've never used 64 bit, but to my current knowledge, wine must be compiled into a 32 bit binaryusing the 32 bit libraries. Looking into how to do this, I only find prebuilt wine packages on the AUR which confuses me: why not have it compile like every other package? Basically, it will take a lot of reading to do this task, and I wish I could do it. But to be honest, it may be a while before *I* will be able to add 64 bit for this.

I would create another package like the others, but that would require that I compile the binary myself and I'm not sure how they went about doing that.

Is there any chance we can get a 64-bit version of this PKGBUILD?

I added the new patch; it should work now.

I removed the patch. If you use compiz wait until later when I create a new patch similar to the old eventc patch.

The eventc patch doesn't work anymore with this latest (1.35).

This PKGBUILD has numerous problems.

dzs6w3, what I would do is grab the latest wine PKGBUILD from [extra], and simply modify it with your patches in source() and md5sums() and build(), and then the pkgname/pkgdesc/provides/conflicts/etc. changes.

Make sure to add || return 1 to the patch lines :)

How can I setup alt+f4 game quit? It doesn't work.

It is fine. I had that error because I was playing warcraft 3 while compiling wine. It probably locked some needed library. Don't know exactly. Compiled it without wc3 running and all went fine. Thx.

Did full system upgrade few hours ago and will try to compile it again. Maybe it was some bug. Will report back.

If nothing is resolved by tomorrow, I will revert back to 1.1.31 if I remember.

I added the patch back, and it built for me. I've heard that the patch fails when applying or something for the newest wine, but everything is working for me, although I do not use composition. The patch failing will not stop the build process, and messages go by too quickly to notice so I don't know. If we cannot resolve these problems I will revert back to 1.1.31 or whatever the latest working version is.

I'm don't know why your build failed. Did it used to build sucessfully?

cdrom.c: In function ‘GetInquiryData’:
cdrom.c:2682: error: ‘INQUIRY’ undeclared (first use in this function)
cdrom.c:2682: error: (Each undeclared identifier is reported only once
cdrom.c:2682: error: for each function it appears in.)
make[2]: *** [cdrom.o] Error 1
make[2]: Leaving directory `/tmp/yaourt-tmp-marko/aur-wine-wc/wine-wc/src/wine-1.1.32/dlls/ntdll'
make[1]: *** [ntdll] Error 2
make[1]: Leaving directory `/tmp/yaourt-tmp-marko/aur-wine-wc/wine-wc/src/wine-1.1.32/dlls'
make: *** [dlls] Error 2
==> ERROR: Build Failed.
Aborting...
Error: Makepkg was unable to build wine-wc package.

Thank you for your efforts.

I'm just now seeing these posts. Anyways, yeah I'll try to restore the patch.

Can you please make it be like before? I could have my other program windows over warcraft without problems. Now I have to push show desktop every time when I try to alt tab. It gets blocked and only show desktop button can unblock it. Can you make it like before please. Thanks.

I have gnome btw, but it is the same in lxde as well.

Nevermind getting the same results as before with emulate virtual desktop.

Dude its better with patch definetly. Without patch I need 1 min to alt tab and go back to game.

I removed a patch since the newest wine fixes the problem with white textures when the window loses focus in OpenGL mode.

I modified it to the previous two poster's likings in this update for 1.1.31.

Just realized, you need provides=('wine') so that this package can be used in conjunction with other packages looking for wine (like winetricks).

I downloaded from abs the 'official' extra/wine PKGBUILD, it does list 'esound' as a makedepends (not esd, somehow). Thing is, someone installing from the AUR would only be creating a package for himself and his own machine, so if he DOES have esound installed, it will be used during makepkg, whether or not its listed in makedepends, while if he DOESN'T have esound installed, it will not be used, and he wouldn't want to install esound so he'd have to edit your PKGBUILD.

I think, since the AUR is for users to self-compile and not create packages to share with other machines, esd should be in optdepends. Not a big deal, however, worse that will happen is some noob installing esd so he can install this package.

I was not sure if I should include packages like esd as dependencies; but I thought that someone might use esd and thus it would be required that wine be compiled witht esd support. It seems that the other packages mark esd as a makedepend. However, you are right on the rest, I will update the package right now.

Hi, your makedepends seems too long, I just successfully compiled without esd and fontforge at least. Perhaps you should refer to the original wine PKGBUILD, with optdepends. wine-w3fix was what I was using before this, his dependency list seems to be identical to the normal wine PKGBUILD. Also namcap would be useful. Thanks for uploading/maintaining this PKGBUILD.

I'll try to. I'm using it too, and I like to keep updated usually. I may lag behind a day or so though occasionally.

thanks, that's very good.

hope you can keep update this PKGBUILD

The patches let you host, alt-tab with compiz running without losing textures, and stay in the channel without crashing constantly.

would please tell me what fixed after enabled these three patches?