Package Details: wine-git 7.3.r297.g99ef287bb72-1

Git Clone URL: (read-only, click to copy)
Package Base: wine-git
Description: A compatibility layer for running Windows programs (git version)
Upstream URL:
Keywords: windows wine
Licenses: LGPL
Conflicts: bin32-wine, wine, wine-wow64
Provides: bin32-wine, wine, wine-wow64
Replaces: bin32-wine
Submitter: None
Maintainer: dbermond
Last Packager: dbermond
Votes: 86
Popularity: 0.107517
First Submitted: 2007-07-18 16:01 (UTC)
Last Updated: 2022-03-08 17:15 (UTC)

Required by (307)

Sources (3)

Latest Comments

ramatullah commented on 2022-06-04 14:19 (UTC)

Has somebody encountered this?

tools/winebuild/winebuild -b x86_64-w64-mingw32 -w --implib -o dlls/winmm/libwinmm.delay.a --export \
/usr/bin/x86_64-w64-mingw32-dlltool: failed to open temporary tail file: winmm_dll_t.o: not found

dbermond commented on 2022-03-28 15:13 (UTC)

@xantares repository wine is compiled with lto disabled, so this flag is not needed. You can compare with repository wine-staging, which does not used this compiler flag, and is basically the same.

xantares commented on 2022-03-28 14:54 (UTC)

wine has -ffat-lto-objects c flag, I dont know if it should be added there too

DarkShadow44 commented on 2022-01-22 19:28 (UTC) (edited on 2022-01-22 19:58 (UTC) by DarkShadow44)

For build I have to add -I/usr/include/freetype2 to CFLAGS. No idea what exactly broke, but this is needed for the 64Bit build.

EDIT: Apparently I lost some files from libsysprof-capture. No idea how, but reinstalling that fixed it...

Neko-san commented on 2022-01-06 22:46 (UTC) (edited on 2022-01-06 22:50 (UTC) by Neko-san)

@rtentser I modified this PKGBUILD yesterday for a different purpose (applying a patch), but you can easily modify what I used for the same purpose (I removed my stuff that's irrelevant to you).

Just edit pkgver, _pkgver, and the checksum for that tarball; then, delete the hidden .SRCINFO file from the snapshot here and run: makepkg --printsrcinfo &> .SRCINFO, rename wine-git.install to wine.install, then you can make the package.

# Maintainer : Daniel Bermond <>
# Contributor: Sidney Crestani <>
# Contributor: sxe <>

pkgdesc='A compatibility layer for running Windows programs (git version)'
arch=('x86_64' 'x86_64_v3')
    'fontconfig'            'lib32-fontconfig'
    'lcms2'                 'lib32-lcms2'
    'libxml2'               'lib32-libxml2'
    'libxcursor'            'lib32-libxcursor'
    'libxrandr'             'lib32-libxrandr'
    'libxdamage'            'lib32-libxdamage'
    'libxi'                 'lib32-libxi'
    'gettext'               'lib32-gettext'
    'freetype2'             'lib32-freetype2'
    'glu'                   'lib32-glu'
    'libsm'                 'lib32-libsm'
    'gcc-libs'              'lib32-gcc-libs'
    'libpcap'               'lib32-libpcap'
    'faudio'                'lib32-faudio'
makedepends=('git' 'autoconf' 'bison' 'perl' 'fontforge' 'flex' 'mingw-w64-gcc'
    'giflib'                'lib32-giflib'
    'libpng'                'lib32-libpng'
    'gnutls'                'lib32-gnutls'
    'libxinerama'           'lib32-libxinerama'
    'libxcomposite'         'lib32-libxcomposite'
    'libxmu'                'lib32-libxmu'
    'libxxf86vm'            'lib32-libxxf86vm'
    'libldap'               'lib32-libldap'
    'mpg123'                'lib32-mpg123'
    'openal'                'lib32-openal'
    'v4l-utils'             'lib32-v4l-utils'
    'libpulse'              'lib32-libpulse'
    'alsa-lib'              'lib32-alsa-lib'
    'libxcomposite'         'lib32-libxcomposite'
    'mesa'                  'lib32-mesa'
    'libgl'                 'lib32-libgl'
    'opencl-icd-loader'     'lib32-opencl-icd-loader'
    'libxslt'               'lib32-libxslt'
    'gst-plugins-base-libs' 'lib32-gst-plugins-base-libs'
    'vulkan-icd-loader'     'lib32-vulkan-icd-loader'
    'vkd3d'                 'lib32-vkd3d'
    'sdl2'                  'lib32-sdl2'
    'libcups'               'lib32-libcups'
    'libgphoto2'            'tar'
    'giflib'                'lib32-giflib'
    'libpng'                'lib32-libpng'
    'libldap'               'lib32-libldap'
    'gnutls'                'lib32-gnutls'
    'mpg123'                'lib32-mpg123'
    'openal'                'lib32-openal'
    'v4l-utils'             'lib32-v4l-utils'
    'libpulse'              'lib32-libpulse'
    'alsa-plugins'          'lib32-alsa-plugins'
    'alsa-lib'              'lib32-alsa-lib'
    'libjpeg-turbo'         'lib32-libjpeg-turbo'
    'libxcomposite'         'lib32-libxcomposite'
    'libxinerama'           'lib32-libxinerama'
    'opencl-icd-loader'     'lib32-opencl-icd-loader'
    'libxslt'               'lib32-libxslt'
    'gst-plugins-base-libs' 'lib32-gst-plugins-base-libs'
    'vulkan-icd-loader'     'lib32-vulkan-icd-loader'
    'vkd3d'                 'lib32-vkd3d'
    'sdl2'                  'lib32-sdl2'
# LTO has to be disabled for 7.0-rc4 or else the build will fail
options=('staticlibs' '!lto')
provides=("wine=${pkgver}" "bin32-wine=${pkgver}" "wine-wow64=${pkgver}")
conflicts=('wine-git' 'bin32-wine' 'wine-wow64' 'wine-staging')

prepare() {
    rm -rf build-{32,64}
    mkdir -p build-{32,64}
    tar xvf ${pkgname}-${_pkgver}.tar.gz
    mv ${pkgname}-${pkgname}-${_pkgver} wine

    # fix path of opencl headers
    sed 's|OpenCL/opencl.h|CL/opencl.h|g' -i wine/configure*

    # fix openldap 2.5+ detection
    sed 's/-lldap_r/-lldap/' -i wine/configure

## Leftover from wine-git PKGBUILD; commented out to prevent makepkg failure
#pkgver() {
#    git -C wine describe --long --tags | sed 's/\([^-]*-g\)/r\1/;s/-/./g;s/^wine.//;s/^v//;s/\.rc/rc/'

build() {
    # workaround for FS#55128
    export CFLAGS="${CFLAGS/-fno-plt/}"
    export LDFLAGS="${LDFLAGS/,-z,now/}"

    # Enforce gcc and g++ and unset potential globally set Clang and any potentially globally set LLVM variables
    export CC=gcc
    export CXX=g++
    export LD=ld
    export AR=""
    export NM=""
    export RANLIB=""
    export STRIP=""
    export OBJCOPY=""
    # Reset debug flags to makepkg.conf defaults, in case Clang is globally set
    export DEBUG_CFLAGS="-g -fvar-tracking-assignments"
    export DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"
    # -O3 optimization because we can :p
    export CFLAGS+=" -O3"
    export LDFLAGS+=" -O3"
    export CROSSCFLAGS=" -g -O3"

    # build wine 64-bit
    # (according to the wine wiki, this 64-bit/32-bit building order is mandatory)
    printf '%s\n' '  -> Building wine-64...'
    cd build-64
    ../wine/configure \
        --prefix='/usr' \
        --libdir='/usr/lib' \
        --with-x \
        --with-gstreamer \

    # build wine 32-bit
    printf '%s\n' '  -> Building wine-32...'
    cd "${srcdir}/build-32"
    export PKG_CONFIG_PATH='/usr/lib32/pkgconfig'
    ../wine/configure \
        --prefix='/usr' \
        --libdir='/usr/lib32' \
        --with-x \
        --with-gstreamer \

package() {
    # package wine 32-bit
    # (according to the wine wiki, this reverse 32-bit/64-bit packaging order is important)
    printf '%s\n' '  -> Packaging wine-32...'
    cd build-32
    make prefix="${pkgdir}/usr" \
         libdir="${pkgdir}/usr/lib32" \
         dlldir="${pkgdir}/usr/lib32/wine" \

    # package wine 64-bit
    printf '%s\n' '  -> Packaging wine-64...'
    cd "${srcdir}/build-64"
    make prefix="${pkgdir}/usr" \
         libdir="${pkgdir}/usr/lib" \
         dlldir="${pkgdir}/usr/lib/wine" \

    # font aliasing settings for win32 applications
    install -d -m755 "${pkgdir}/usr/share/fontconfig/conf.default"
    install -D -m644 "${srcdir}/30-win32-aliases.conf" -t "${pkgdir}/usr/share/fontconfig/conf.avail"
    ln -s ../conf.avail/30-win32-aliases.conf "${pkgdir}/usr/share/fontconfig/conf.default/30-win32-aliases.conf"

    # wine binfmt
    install -D -m644 "${srcdir}/wine-binfmt.conf" "${pkgdir}/usr/lib/binfmt.d/wine.conf"

    # strip native PE libraries
    i686-w64-mingw32-strip --strip-unneeded "${pkgdir}/usr/lib32/wine/i386-windows"/*.dll
    "${CARCH}-w64-mingw32-strip" --strip-unneeded "${pkgdir}/usr/lib/wine/${CARCH}-windows"/*.dll

dbermond commented on 2021-03-30 00:01 (UTC)

@katt implemented.

katt commented on 2021-03-29 13:46 (UTC)

Could you include the recent fontconfig changes?

dbermond commented on 2021-01-09 15:19 (UTC)

@rtentser This package is not for building older versions of wine, and neither for bisecting, but it's for building the latest git master code.

rtentser commented on 2021-01-09 05:49 (UTC)

@katt I want to be able to build older versions of wine from this package for bisecting.

katt commented on 2021-01-08 22:12 (UTC)

@rtentser Sounds like you want wine-stable.

rtentser commented on 2021-01-02 05:32 (UTC)

Can't build wine-5.0 with this.

winebuild: /usr/bin/ld failed with status 1 winegcc: ../../tools/winebuild/winebuild failed make[1]: [Makefile:755:] Error 2 make[1]: Leaving directory '/home/rtentser/Sources/AUR/wine-git/src/build-64/dlls/crypt32' make: [Makefile:9177: dlls/crypt32] Error 2 ../../tools/winegcc/winegcc -o ctapi32.dll.fake --wine-objdir ../.. -m64 -fPIC -fasynchronous-unwind-tables \ -shared ../../../wine/dlls/ctapi32/ctapi32.spec ctapi32.o -ladvapi32 \ ../../libs/port/libwine_port.a -Wl,-O1,--sort-common,--as-needed,-z,relro make: *** Waiting for unfinished jobs.... ../../../tools/winegcc/winegcc -o cryptui_test-stripped.exe --wine-objdir ../../.. -b x86_64-w64-mingw32 \ --lib-suffix=.cross.a -s -Wb,-F,cryptui_test.exe -mno-cygwin cryptui.cross.o testlist.cross.o \ ../../../dlls/cryptui/libcryptui.cross.a ../../../dlls/crypt32/libcrypt32.cross.a \ ../../../dlls/user32/libuser32.cross.a ../../../tools/winegcc/winegcc -o cryptui_test.exe --wine-objdir ../../.. -b x86_64-w64-mingw32 \ --lib-suffix=.cross.a -mno-cygwin cryptui.cross.o testlist.cross.o \ ../../../dlls/cryptui/libcryptui.cross.a ../../../dlls/crypt32/libcrypt32.cross.a \ ../../../dlls/user32/libuser32.cross.a echo "cryptui_test.exe TESTRES \"cryptui_test-stripped.exe\"" | ../../../tools/wrc/wrc -o ../../../programs/winetest/cryptui_test.res make[1]: Leaving directory '/home/rtentser/Sources/AUR/wine-git/src/build-64/dlls/cryptui/tests' make[1]: Leaving directory '/home/rtentser/Sources/AUR/wine-git/src/build-64/dlls/ctapi32' ==> ERROR: A failure occurred in build(). Aborting...

dbermond commented on 2020-01-03 19:52 (UTC)

@ekce xorgproto is being automatically pulled. Package is currently building fine without modifications.

ekce commented on 2019-12-21 18:29 (UTC)

This package now requires xorgproto.

dbermond commented on 2019-04-19 17:04 (UTC) (edited on 2019-04-19 17:05 (UTC) by dbermond)

@electricprism The version will be automatically updated by the pkgver() function when you run makepkg. No need to update the major version at each upstream release. This is how VCS packages work. See the Wiki:

electricprism commented on 2019-04-14 21:49 (UTC)

I noticed that the version on this package is 3.18 prefix but current version of wine is 4.6

Maybe if you want to drop the subversion and keep the main number which will increment annually that might be a good idea or use something else to minimize confusion I'd like to suggest it.

Tom_B commented on 2018-10-22 13:23 (UTC)

I'm not sure why but using this package, I cannot use Steam in offline mode. The standard arch package works fine but with wine-git steam via wine doesn't connect. Is there something I can add to the ./configure or make line to enable networking?

I'm not sure if it's a problem with wine itself or this package but it makes it slightly difficult to try custom patches in wine if you need to test a steam game.

dbermond commented on 2018-10-11 21:41 (UTC)

@Morguldir Thank you for reporting this. Package updated.

morguldir commented on 2018-10-10 16:56 (UTC)

They applied the freetype patch upstream

dbermond commented on 2018-07-03 17:12 (UTC)

@Enverex If you are building with avx support enabled then you're modifying the default Arch Linux build flags. By doing this you're pretty aware of the issues that it can cause (like the one you're having). Users wanting the most vanilla experience should 1) not modify the build flags, and/or 2) build the package in a clean chroot. It's user reponsibility to control the build flags, unless some major intervention is required.

Forcedly disabling avx support is not a good idea. Firstly, because it's not intended to use avx by default in any way (due to the default Arch build flags being x86_64 generic ones). Secondly, because it will impact users that want to benefit from avx support. Thirdly, because this is affecting only your application. If it would be a broad wine issue affecting a huge amount of applications, then well, we could disable avx here, but this is not the case.

I suggest you to fill a bug report in upstream wine saying that you're having issues in your application when avx is enabled, instead of asking for forcedly disabling avx here.

Enverex commented on 2018-06-29 12:49 (UTC)

@dbermond - Wine will literally just crash if it tries to use it, there is no benefit to leaving it enabled. You have 2 possible situations:

  1. The user doesn't have an AVX capable CPU, the flag won't do anything because AVX was never supported in the first place.

  2. The user has an AVX capable CPU. As soon as Wine tries to use AVX, Wine will crash. Adding the flag negates this situation.

Essentially leaving AVX enabled will do nothing other than cause Wine to crash whenever it's used (universally, until it's fixed upstream, if that will actually happen). There is zero positive to enabling the flag (which will be enabled by default for anyone using native or CPU specific compiler flags).

But it's up to you.

dbermond commented on 2018-06-05 15:26 (UTC)

@Enverex I don't think it's a good idea to force users to compile without avx support. It can be a user choice to use avx.

Enverex commented on 2018-06-04 14:32 (UTC)

@dbermond - I've actually tracked down the real reason now. It will technically affect anyone with an AVX capable processor but only triggers in very rare circumstances:

May be worth adding "-mno-avx" to C/XXFLAGS in the build section somewhere to negate it.

dbermond commented on 2018-06-03 02:28 (UTC)

@Enverex I'm glad that you found the answer. But yes, this package is the same as wine from the official repositories, except for being the development version.

Packages from the official repositories are built in a clean chroot to avoid linking against undesired libraries and other interferences that may occur. For example, in a chroot it will not link against any nvidia specific library that the user might have installed. In order to better reproduce the official repository package, the user should build it in a clean chroot. And as you know, official repository packages are built with generic x86_64 compiler flags, and this can also cause runtime differences.

Enverex commented on 2018-06-02 22:25 (UTC) (edited on 2018-06-02 23:07 (UTC) by Enverex)

Cemu crashes in Mario Kart 8 with this (even when set to the 3.9 release commit specificall) but not the stock repo Wine.

The actual build looks pretty much the same between this and the stock Arch repo version. Is there anything else different in the build script here that could be responsible for this different behaviour?

EDIT: Looks like it may be a GCC issue. It only happens if compiled with -march=native (i7-8700K).

dbermond commented on 2017-12-11 19:26 (UTC)

@EndlessEden Segfault at compile time? Package is building fine for me.

EndlessEden commented on 2017-12-11 09:03 (UTC)

i segfault with this. idk why...

dbermond commented on 2017-10-10 20:35 (UTC)

I'm maintaining this package now. After some cleanups, it's now building and working fine. Enjoy.

Vash63 commented on 2017-09-28 06:09 (UTC)

Follow up - #2 below was fixed, I can now build and use wine-git when removing the Flex.patch and with no other changes.

Vash63 commented on 2017-09-27 09:57 (UTC)

1. Flex patch should no longer be necessary, the bug report indicates this was fixed in 2.6.4 in May. 2. Unfortunately this can't be built at all with Fontconfig 2.8.1 due to: Not sure if there's a patch you could do here without requiring a downgrade of Fontconfig.

sidneycrestani commented on 2017-02-16 00:00 (UTC)

@greyltc flex team solved the issue in a january commit. I added a workaround anyway.

greyltc commented on 2017-02-12 14:32 (UTC)

It seems like flex is somehow being left out of the build system right now and that's why the build has failed for me. To fix this, make sure you have flex and lib32-flex installed, then you have to get "-lfl" into the end build command for winhlp32. Here are the (super hacky) changes I made to the PKGBUILD here to get the build to complete. - Add flex and lib32-flex to makedepends - Add the following sed command to the build() function just before the make command for the 64 bit build: sed -i 's|-lcomctl32 -lcomdlg32 -luser32 -lgdi32 \.\./\.\./libs/port/libwine_port\.a -Wb,-dshell32 -Wb,-dcomctl32 \\|-lcomctl32 -lcomdlg32 -luser32 -lgdi32 -lfl \.\./\.\./libs/port/libwine_port\.a -Wb,-dshell32 -Wb,-dcomctl32 \\|g' programs/winhlp32/Makefile - Add the following sed command to the build() function just before the make command for the 32 bit build: sed -i 's|macro\.lex\.yy\.o winhlp32\.res -lshell32 -lcomctl32 -lcomdlg32 -luser32 -lgdi32 \\|macro\.lex\.yy\.o winhlp32\.res -lshell32 -lcomctl32 -lcomdlg32 -luser32 -lgdi32 -lfl \\|g' programs/winhlp32/Makefile

greyltc commented on 2017-02-12 12:35 (UTC)

The build is failing with macro.lex.yy.c:(.text+0xf4d): undefined reference to `yywrap' as follows make[1]: Entering directory 'wine-git/src/wine-git-64-build/programs/winetest' build="BUILD_INFO STRINGRES build.nfo STRINGTABLE { 1 \"`GIT_DIR=../../../wine-git/.git git rev-parse HEAD 2>/dev/null`\" }" && (echo $build | cmp -s - build.rc) || echo $build >build.rc || (rm -f build.rc && exit 1) make[1]: Leaving directory 'wine-git/src/wine-git-64-build/programs/winetest' make[1]: Entering directory 'wine-git/src/wine-git-64-build/programs/winhlp32' ../../tools/winegcc/winegcc -o -B../../tools/winebuild -m64 -fasynchronous-unwind-tables \ -mwindows callback.o hlpfile.o macro.o string.o winhelp.o macro.lex.yy.o winhlp32.res -lshell32 \ -lcomctl32 -lcomdlg32 -luser32 -lgdi32 ../../libs/port/libwine_port.a -Wb,-dshell32 -Wb,-dcomctl32 \ -Wb,-dcomdlg32 -Wl,-O1,--sort-common,--as-needed,-z,relro macro.lex.yy.o: In function `yylex': macro.lex.yy.c:(.text+0xf4d): undefined reference to `yywrap' collect2: error: ld returned 1 exit status winegcc: gcc failed make[1]: *** [Makefile:353:] Error 2 make[1]: Leaving directory 'wine-git/src/wine-git-64-build/programs/winhlp32' make: *** [Makefile:20951: programs/winhlp32] Error 2 Is this upstream's problem or ours?

z3ntu commented on 2017-01-11 13:09 (UTC)

flex 2.6.3-1 seems to break the compilation. Downgrading to 2.6.1-1 ( fixes it.

sidneycrestani commented on 2016-12-07 00:04 (UTC)

the --with-gstreamer option is already there, that comment is from the community repo your issue #2 was fixed on my second commit

C0rn3j commented on 2016-12-06 17:11 (UTC)

Thanks! That seems to have fixed it! I just have 2 issues left with this package 1)# Gstreamer was disabled for FS#33655 As you can see this issue was fixed upstream. 2) My comment from 2016-11-20 13:36 on this page describes the issue

sidneycrestani commented on 2016-12-06 00:22 (UTC) (edited on 2016-12-06 01:01 (UTC) by sidneycrestani)

I copied the PKGBUILD dependencies from upstream, my bad EDIT: Should be fixed now

C0rn3j commented on 2016-12-05 22:28 (UTC)

Thanks for taking over the package and fixing the issues, but now there's a problem with - mesa-libgl (package found) [makedepend] - lib32-mesa-libgl (package found) [makedepend] :: mesa-libgl and nvidia-libgl are in conflict (libgl). Remove nvidia-libgl? [y/N] Tl;dr people with binary Nvidia drivers are being forced to use mesa

C0rn3j commented on 2016-12-04 00:46 (UTC)

The lines that's twice in the PKGBUILD: libcl lib32-libcl need to be replaced by: opencl-icd-loader lib32-opencl-icd-loader Because of recent changes.

C0rn3j commented on 2016-11-20 13:36 (UTC)

Installing this package removes `wine` package, which requires removing packages like `winetricks-git`/`winetricks`/`wine-mono`/`wine_gecko` as they rely on `wine`, so it'd be great if the PKGBUILD was edited to provide `wine` or whatever change needs to be done to not break other packages.

sxe commented on 2016-05-14 09:38 (UTC)

Hey guys, i merged the latest wine PKGBUILD changes, builds fine for me now. @Xylemon I would like to keep in sync with the original wine PKGBUILD as close as possible. Greetings

Xylemon commented on 2016-04-08 18:11 (UTC) (edited on 2016-04-08 18:14 (UTC) by Xylemon)

Could you add OSS to the optional deps as well?

dickiteemerald commented on 2016-03-13 03:03 (UTC)

Hey there I had to compile latest wine but wasn't succesful in building a clean pkgbuild for diablo III

davispuh commented on 2015-07-27 22:33 (UTC)

There's a couple of GCC bugs for 5.x which makes compiling wrong code for Wine so I recommend using gcc-multilib-git until fixed GCC is released. Or alternatively you can use workaround by compiling with "-O0" in CFLAGS or compile with GCC 4.9

Soukyuu commented on 2015-06-05 11:48 (UTC)

To answer my own question:

Soukyuu commented on 2015-05-27 15:44 (UTC)

Interesting. After replacing the stable version with this one, my win64 prefix stopped working: err:process:start_wineboot failed to start wineboot, err 1359 err:module:attach_process_dlls "gdi32.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"C:\\windows\\system32\\explorer.exe" failed, status c0000005 fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub Application tried to create a window, but no driver could be loaded. The explorer process failed to start. I can't even start winecfg anymore. Win32 prefix has no problems. Any ideas?

sxe commented on 2015-01-11 10:58 (UTC)

Hi xymostech, thanks for pointing that out I fixed it. Greetings

xymostech commented on 2014-05-29 01:30 (UTC)

It looks like, with the current PKGBUILD, you can't install things like wine_gecko or wine-mono because they depend on a specific version of wine, and this package provides wine but without a version. Adding a line like provides[2]="wine=$(cd "$srcdir/$pkgname" && git describe --always --long | cut -d '-' -f 2)" inside of package() (so provides ends up looking like '(bin32-wine wine-wow64 wine=1.7.19)') seems to fix this. There's probably a more elegant way to fix this.

acidicX commented on 2014-04-05 17:23 (UTC)

Somehow the dependencies are broken? AUR page just displays [@]/*32-*/}[@]} ... same with wine-stable in AUR. Cannot build it with aura either: aura: InvalidUrlException "[@]}/PKGBUILD" "Invalid URL"

sxe commented on 2014-02-04 10:26 (UTC)

You are right oscode, fixed. I also changed the version format to a git tag / version combination, so makepkg can see if there are changes in the git checkout. Now the package is only build when it is necessary.

oscode commented on 2014-01-24 19:42 (UTC)

I know it's obvious from the title that git is going to be a dependency, but it isn't a dependency in the PKGBUILD.

sxe commented on 2014-01-18 10:46 (UTC)

Thanks haagch for your investigation. I've added a check to the PKGBUILD. The PKGBUILD now makes sure libowfat is not installed before continuing.

haagch commented on 2014-01-16 20:53 (UTC)

Now I finally researched a bit. If you have libowfat installed, the wine build will use a bunch of headers from libowfat like /usr/include/uint64.h and apparently there somewhere is the cause of the conflict. Maybe there should be a conflict with libowfat or maybe a workaround in the package.

sxe commented on 2013-12-07 09:57 (UTC)

Merged the latest WINE PKGBUILD changes. Besides that i get no errors at all.

haagch commented on 2013-12-05 13:45 (UTC)

For me it is conflicting declaration. In file included from /usr/include/tiffio.h:33:0, from ../../../wine-git/dlls/windowscodecs/tiffformat.c:27: /usr/include/tiff.h:77:23: Fehler: In Konflikt stehende Typen für »int64« typedef TIFF_INT64_T int64; ^ and In file included from /usr/include/tiffio.h:33:0, from ../../../wine-git/dlls/windowscodecs/tiffformat.c:27: /usr/include/tiff.h:78:23: Fehler: In Konflikt stehende Typen für »uint64« typedef TIFF_UINT64_T uint64; ^ That's from libtiff from extra..

hepha commented on 2013-12-01 14:56 (UTC)

fix "Wine cannot find the ncurses library (" sed -e 's|libncurses|libncursesw|g' -e 's|lncurses|lncursesw|g' -i configure

jonnybarnes commented on 2013-05-12 18:14 (UTC)

The lack of a is a known issue. In theory this bugfix should solve the issue: However, I can't seem to get the patch applied at the moment.

jonnybarnes commented on 2013-05-12 17:04 (UTC)

It's definitely not the patches, I've just tried to compile this with the default PKGBUILD, the resulting binary won't run because it can't find the file

jonnybarnes commented on 2013-05-11 15:34 (UTC)

Hi, I'm trying to compile this with some patches from one of the winehq big reports. It worked before. And it seems to be working now. But the packaged .xz file doesn't have a file /usr/lib/ and thus trying to run wine results in an error of being unable to find the file. Does anyone know how to fix this?

sxe commented on 2013-04-24 17:38 (UTC)

ok, next try. Sry, i'm really busy lately so i need some time to react to your comments.

TheWaffleGuy commented on 2013-04-22 18:50 (UTC)

Sorry, no. The unstripped depends still gets added to makedepends. If i change it to the stripped one this is still overridden by the first line in the package function, depends=(${_depends[@]}) . You should probably either move this line so that it's only run on 64bit systems or change so that the stripped array is saved back to _depends instead of depends, that is change depends=(${_depends[@]/*32-*/}) to _depends=(${_depends[@]/*32-*/})

sxe commented on 2013-04-22 17:16 (UTC)

You are right, sry i fucked that one up. Please let me know if it works now.

TheWaffleGuy commented on 2013-04-22 15:50 (UTC)

Hi. I've got some problems with this package. Where you test if arch is i686, and strip lib32 depends, you are using the variable depends when you should be using _depends, change depends=(${depends[@]/*32-*/}) to _depends=(${_depends[@]/*32-*/}) . Without this change makepkg complains that it can't find the lib32* packages on an 32bit install.

Wintershade commented on 2013-04-21 10:03 (UTC)

Hello, I'm having trouble with this package, as well as the stock WINE package from [multilib]. Essentially, winecfg and wineboot (and supposedly ALSA) fail on a 64-bit wineprefix. There are three of us (that I know) currently experiencing this problem. I've opened a thread in the Arch BBS, if you'd like to check it out (I'd be very grateful): TIA :)

sxe commented on 2013-04-20 10:19 (UTC)

As Adys suggested the package now uses the new vcs PKGBUILD functionality. Furthermore i merged the PKGBUILD with the latest changes from the wine PKGBUILD. Greetings

jleclanche commented on 2013-04-19 22:20 (UTC)

With pacman 4.1, this could benefit from the new-style vcs pkgbuilds.

commented on 2013-03-15 00:16 (UTC)

I receive this when I attempt to compile: ../../wine-git/include/objidl.idl:32: error: syntax error, unexpected aIDENTIFIER make[1]: *** [netcon.h] Error 1 make[1]: Leaving directory `/var/abs/local/yaourtbuild/wine-git/src/wine-git-64-build/include' make: *** [include] Error 2

sxe commented on 2013-01-02 11:11 (UTC)

Merged the latest wine PKGBUILD changes. @TheJJ Thx for the suggestion, seems a good idea, i have added it.

quetzal commented on 2012-12-19 18:00 (UTC)

Libs are missing on 64bits (not on the repo) lib32-giflib lib32-libxmu lib32-libxml2 lib32-lcms lib32-mpg123

TheJJ commented on 2012-10-05 23:17 (UTC)

to speed up downloading, you could enable shallow cloning: git clone --depth 1

sxe commented on 2012-07-27 18:23 (UTC)

No problem here. Builds just fine. What is the error message?

commented on 2012-07-27 13:58 (UTC)

I can not compile this on x64: missing the 32bit freetype2 libraries. Installed these libs and also bin32-freetype2 as suggested, but still the same error

sxe commented on 2012-04-17 08:25 (UTC)

I don't know what you are talking about, it looks out for this: 'gcc>=4.5.0-2' 'gcc-multilib>=4.5.0-2' Works fine here.

Aelius commented on 2012-04-17 00:54 (UTC)

fails because gcc 4.7.0-4 is out and it only looks for 4.7.0

sxe commented on 2012-03-17 10:11 (UTC)

Hi drstein, i don't know whats the problem. It compiles fine on my computer (64 bit as well). Anyway, i merged the package with the latest wine package from community. Have a try again, maybe it was a temporary problem with the GIT version.

commented on 2012-03-16 01:33 (UTC)

I'm having trouble compiling wine, tried some other versions but just cant figure it out... wine from official repository works fine. Heres my error log:

dot commented on 2012-02-06 09:24 (UTC)

this solved the problem, thanks!

vodik commented on 2012-02-04 13:02 (UTC)

Its not missing, it just shouldn't be an array. Change it to install='wine-git.install'

dot commented on 2012-02-01 18:51 (UTC)

the package misses wine-git.install file referenced in PKGBUILD:16: 16 install=(wine-git.install) ==> Building and installing package ==> ERROR: install file ((wine-git.install)) does not exist. ==> ERROR: Makepkg was unable to build wine-git.

commented on 2012-01-31 10:00 (UTC)

OpenAL isn't correctly detected by the build system, it seems. I had to swap references to /usr/include/OpenAL/AL.h to usr/include/AL/AL.h

sxe commented on 2012-01-01 21:52 (UTC)

nop, works fine here. Also arch 64.

commented on 2012-01-01 14:41 (UTC)

I dunno if anyone else is facing this problem but i get: "wine: failed to initialize: dlopen interface not detected by configure following" following msg after compile and install. all upgraded arch linux x86_64. And the package provided by repo is broken for mouse as it has xinput2 enabled which is broken for many games that i use so i need compile this again without xinput2

korrode commented on 2011-12-27 12:54 (UTC)

if [[ $CARCH == i686 ]]; then # Strip lib32 etc. on i686 depends=(${depends[@]/*32-*/}) makedepends=(${makedepends[@]/*32-*/}) makedepends=(${makedepends[@]/*-multilib*/}) optdepends=(${optdepends[@]/*32-*/}) else provides=("wine=$pkgver" "bin32-wine=$pkgver" "wine-wow64=$pkgver") conflicts=("wine" 'bin32-wine' 'wine-wow64') replaces=("wine" 'bin32-wine') fi --------------------------------------------- Is not the problem obvious? There's only provides/conflicts/replaces if $CARCH isn't i686.

sxe commented on 2011-11-12 10:26 (UTC)

Can anyone confirm this? I have no i686 installation to test it. On 64bit everything works like expected.

commented on 2011-11-09 20:35 (UTC)

Having dependency problems. On i686 it looks like "provides", "conflicts" and "replaces" are *not* set. I discovered this when I tried to install and wine-git did not complain about my existing wine installation at first (I ended up removing it manually). pacman -Qi does not list any "provides", "conflicts" or "replaces". This is a problem if I want to install Arch's wine-gecko!

rwd2 commented on 2011-10-13 09:45 (UTC)

namcap lists some dependency issues: missing dependencies for libgphoto2 and gettext, and several included dependencies that are optional

sxe commented on 2011-10-11 18:52 (UTC)

thx, fixed

xphoniexx commented on 2011-10-11 03:30 (UTC)

Howdy, Wine is listed as an unnecessary makedepends of itself in the PKGBUILD file. 'makedepends=(wine autoconf ncurses bison perl fontforge flex prelink'

sxe commented on 2011-10-06 09:39 (UTC)

Hi feilen, do you have any problems with CoreAudio while compiling? I prefer keeping the wine-git PKGBUILD as close as possible to the original wine PKGBUILD.

feilen commented on 2011-10-06 06:52 (UTC)

Couldn't you add --without-coreaudio to the configure options? CoreAudio is for Macs.

sxe commented on 2011-09-06 07:03 (UTC)


commented on 2011-08-12 15:17 (UTC)

If I'm not mistaken, git should be added to the list of build dependencies.

sxe commented on 2011-08-03 18:58 (UTC)

Hey tea, you were right, lib32-bzip2 was the missing dependency. I could not see it, cause my mirror was not up to date. I also contacted the wine maintainer earlier, so they updated the bin32-freetype2 package, which has now the correct dependencies, so no need to add lib32-bzip2 to makedepend. The package should work now.

tea commented on 2011-08-03 16:57 (UTC)

It just got moved to [multilib].

sxe commented on 2011-08-03 15:10 (UTC)

Where did you find lib32-bzip2? Its not in teh AUR for me.

tea commented on 2011-08-03 14:31 (UTC)

Build fixed by installing lib32-bzip2 from the AUR. Might be an idea to add that as a makedepend.

sxe commented on 2011-08-02 10:29 (UTC)

Thx for the info tea. It seems to be a general wine problem, cause the normal wine package is broken too (at least on 64bit systems). I'm working on it.

tea commented on 2011-08-01 22:41 (UTC)

I'm having trouble compiling. It's missing the 32bit freetype2 libraries, apparently. lib32-freetype2 is definitely installed. Not sure what package would provide whatever's missing.

feilen commented on 2011-07-17 19:35 (UTC)

Anyone having any luck compiling this with LTO? For me it silently fails when trying to link wineserver-installed.

commented on 2011-02-13 10:22 (UTC)

--> resolving ${depends[@]/*32-*/}... unresolvable --> resolving ${makedepends[@]/*-multilib*/}... unresolvable That's what I get when trying to build. I'm using bauerbill right now. I'm going to try and change the PKGBUILD.

sxe commented on 2011-01-25 22:13 (UTC)

Is only that package missing? Do you have multilib repositorys installed? Here is what i get: yaourt -Ss lib32-libxrandr multilib/lib32-libxrandr 1.3.1-1 [installed] X11 RandR extension library (32-bit)

commented on 2011-01-25 22:03 (UTC)

I'm on x86_64 and building this with yaourt and it can't find lib32-libxrandr anywhere. Any idea what's up?

commented on 2011-01-21 08:23 (UTC)

i have mingw32 crosscompiler installed and compiling fail's for me, i trying to fix it manually, i will report if found solution, appending --host and --build to configure does not solve this, but at least it trying to build with right toolset.

sxe commented on 2010-12-18 11:53 (UTC)

For me it works both ways, with and without "master" added. Anyway i updated the PKGBUILD to make it working for all again. thx for the tip Ockonal.

commented on 2010-12-17 17:23 (UTC)

Failed to fetch source from git with latest pkgbuild. Edit PKGBUILD-file, find line `cd $pkgname && git pull origin` and add `master`. It should be like: `cd $pkgname && git pull origin master` now.

sxe commented on 2010-12-11 18:57 (UTC)

i'm the new maintainer, so hopefully the pakage works for all of you guys.

sxe commented on 2010-12-06 20:52 (UTC)

I sent intellitech a mail. We'll see if he responses otherwise a AUR admin has to change the PKGBUILD.

lubosz commented on 2010-12-06 20:16 (UTC)

With sxe's PKGBUILD i was able to build wine in arch64 for the first time, without any chroot. $ wine --version wine-1.3.8-291-g0a55ec2 There is no reason for intellitech's PKGBUILD to exist. Arch changed the whole handling of multilib since this pkgbuild was written. Please replace it with the actually working one.

lubosz commented on 2010-12-06 19:53 (UTC)

Dependency `lib32-dbus' of `wine-git' does not exist.

sxe commented on 2010-11-23 10:33 (UTC)

like i said, mine is based on the multilib/wine PKGBUILD. I think thats the reason.

commented on 2010-11-23 06:35 (UTC)

I was looking over intellitech and sxe's PKGBUILDs, why do they have different dependencies?

sxe commented on 2010-10-20 15:33 (UTC)

your welcome. :) So we need at least one 32 bit tester before i can get in touch with intellitech to replace its PKGBUILD with mine.

commented on 2010-10-20 14:13 (UTC)

I've tested the sxe's PKGBUILD on my arch64 and works fine! I vote to replace the PKGBUILD. Great job sxe! ;D

sxe commented on 2010-09-28 15:54 (UTC)

Hey guys, i modified the wine PKGBUILD to work with the latest wine git version. I have a 64 bit system and here and everything works fine. Could someone test it and give me some feedback. 32 and 64 bit testers would be nice. You can get the PKGBUILD here:

xyproto commented on 2010-09-14 16:51 (UTC)

Please change lib32-dbus to lib32-dbus-core. Also, this PKGBUILD might be of help to be able to build wine:

sxe commented on 2010-08-15 12:45 (UTC)

still not working. Getting the same error "Cannot build a 32-bit program, you need to install 32-bit development libraries.".

intellitech commented on 2010-07-26 16:12 (UTC)

whiteychs - You're right, one will likely need to do this in a chroot. I haven't been able to successfully build it on x86_64, but it's theoretically possible. gueek - depends array has been fixed.

commented on 2010-07-25 23:30 (UTC)

Building is broken for x86_64 as below poster stated. "configure: error: Cannot build a 32-bit program, you need to install 32-bit development libraries." I don't think you can compile this without a chroot for 64bit users...

commented on 2010-07-21 11:51 (UTC)

sorry, I meant "lib32", not "bin32".

commented on 2010-07-16 13:58 (UTC)

is the "depends" array supposed to be composed exclusively of packages for x64? they're all prefixed by "bin32", and won't build on my x86 system (as expected). I removed all the bin32 prefixes, and I'm waiting for the build to finish. is 1.2 x64-only? I'm confused. maybe you just forgot to differenciate the depends, but I really don't know, so I'll just post this: depends=('fontconfig' 'libxxf86dga' 'mesa' 'libxcursor' 'libxrandr' 'libxdamage' 'libldap' 'libxslt' 'lcms' 'mesa' 'libpng>=1.4.0')

intellitech commented on 2010-07-13 17:12 (UTC)

IncredibleLaser - It was commented out, not exactly warranting a PKGBUILD update. Either way, the package has been updated, with changes made to depends/makedepends/conflicts.

IncredibleLaser commented on 2010-07-04 13:32 (UTC)

There are some issues with your PKGBUILD. 1. Most of your depends are makedepends. Check out the official wine PKGBUILD. Also, your alignment is not very readable. 2. provides=("wine-git=$pkgver" ...) is unnecessary. Better: provides=("wine=1.2") or whichever is the next version of wine. 3. conflicts=(... 'wine-git') is wrong. A package cannot conflict itself. 4. # patch -p1 < ${startdir}/patchfile.diff is commented out, but never use $startdir. Add your patches to the sources array and refer to them as ${srcdir}/patchname later. Also, add "|| return 1" to your patchlines. 5. I don't know if necessary, but have a look at the official PKGBUILD for configure-options.

Noctivivans commented on 2010-06-21 12:55 (UTC)

On Arch x86_64 I got configure error: checking whether gcc -m32 works... no configure: error: Cannot build a 32-bit program, you need to install 32-bit development libraries.