@Tomoghno nope, there are repos packaging this PKGBUILD out there, you can use one of those. Also, PKGBUILDs packaging the binary results of other PKGBUILDs are STRICTLY prohibited in the AUR.
Search Criteria
Package Details: wine-ge-custom 1:GE.Proton8.26-6
Package Actions
Git Clone URL: | https://aur.archlinux.org/wine-ge-custom.git (read-only, click to copy) |
---|---|
Package Base: | wine-ge-custom |
Description: | A compatibility layer for running Windows programs - GloriousEggroll branch |
Upstream URL: | https://github.com/GloriousEggroll/wine-ge-custom |
Licenses: | LGPL-2.1-or-later |
Conflicts: | wine |
Provides: | wine |
Submitter: | loathingkernel |
Maintainer: | loathingkernel |
Last Packager: | loathingkernel |
Votes: | 39 |
Popularity: | 0.69 |
First Submitted: | 2021-09-01 22:06 (UTC) |
Last Updated: | 2024-10-02 16:21 (UTC) |
Dependencies (103)
- attr (attr-gitAUR)
- desktop-file-utils (desktop-file-utils-gitAUR)
- fontconfig (fontconfig-gitAUR, fontconfig-ubuntuAUR)
- freetype2 (freetype2-qdoledAUR, freetype2-macosAUR, freetype2-gitAUR)
- gcc-libs (gcc-libs-gitAUR, gccrs-libs-gitAUR, gcc11-libsAUR, gcc-libs-snapshotAUR)
- gettext (gettext-gitAUR)
- lib32-attr
- lib32-fontconfig
- lib32-freetype2
- lib32-gcc-libs (lib32-gcc-libs-gitAUR, lib32-gccrs-libs-gitAUR, lib32-gcc-libs-snapshotAUR)
- lib32-gettext
- lib32-libpcap
- lib32-libxcursor
- lib32-libxi
- lib32-libxrandr
- libpcap (libpcap-gitAUR)
- libxcursor
- libxi (libxi-gitAUR)
- libxrandr (libxrandr-gitAUR)
- alsa-lib (make)
- Show 83 more dependencies...
Required by (379)
- 0cc-famitracker (requires wine)
- 2gis (requires wine)
- 4nec2-bin (requires wine)
- accutimes (requires wine)
- adobe-reader-11 (requires wine)
- ag-dsp-controller (requires wine)
- ags-git (requires wine) (optional)
- aimp (requires wine)
- aio-creator-neo (requires wine)
- alchemy-viewer-git (requires wine) (optional)
- algodoo-wine (requires wine)
- altirra (requires wine)
- anituner (requires wine)
- ankama-launcher (requires wine) (optional)
- anycubic-slicer (requires wine)
- aoe3-wine-steam (requires wine)
- arch-gaming-meta (requires wine)
- ares (requires wine)
- asim (requires wine)
- Show 360 more...
Sources (7)
Latest Comments
« First ‹ Previous 1 .. 7 8 9 10 11 12 13 Next › Last »
loathingkernel commented on 2021-10-07 12:05 (UTC) (edited on 2021-10-07 12:05 (UTC) by loathingkernel)
Tomoghno commented on 2021-10-07 11:56 (UTC)
Can You Make a Binary Package for it ...
loathingkernel commented on 2021-09-27 15:06 (UTC) (edited on 2021-09-27 16:12 (UTC) by loathingkernel)
@kenga I moved a few environment variables around and it should be ok with yay
too now. That being said I still believe that the assumptions yay
is making are wrong and they definitely are not the default behavior of makepkg
. Just something to keep in mind if other issues arise with it.
kenga commented on 2021-09-27 14:48 (UTC)
Yep, building directly with makepkg seems to work. Quite annoying, as yay
had been playing nice so far.
Well, time to retire yet another helper I suppose...
loathingkernel commented on 2021-09-26 23:13 (UTC) (edited on 2021-09-26 23:44 (UTC) by loathingkernel)
I don't know what shitty things yay
is doing and why but it doesn't follow the assumed makepkg
way and it doesn't retain the environment between prepare()
and build()
as evident by the existence of filtered flags in your log. My guess is that it first prepares the sources and then starts the build again with a new environment for some reason.
Package builds fine in a clean chroot with Arch's proper tooling.
loathingkernel commented on 2021-09-26 22:39 (UTC) (edited on 2021-09-26 22:52 (UTC) by loathingkernel)
@kenga what distro are you on and are you using a helper? Try without a helper and if it persists, report back.
kenga commented on 2021-09-26 22:02 (UTC)
Fails for me without without any modifications of the PKGBUILD as well (6.18.GE.1-1, PKGBUILD commit a7aae53a9ff4)
<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
/home/user/.cache/yay/wine-ge-custom/src/wine-ge-custom-64-build/tools/winebuild/winebuild -w --def -o dlls/kernel32/libkernel32.def \
-m32 --export ../wine-ge-custom/wine/dlls/kernel32/kernel32.spec
/home/user/.cache/yay/wine-ge-custom/src/wine-ge-custom-64-build/tools/winegcc/winegcc -o dlls/capi2032/capi2032.dll.so \
--wine-objdir . --winebuild \
/home/user/.cache/yay/wine-ge-custom/src/wine-ge-custom-64-build/tools/winebuild/winebuild -m32 \
-fno-PIC -Wl,-z,notext -fasynchronous-unwind-tables -shared \
../wine-ge-custom/wine/dlls/capi2032/capi2032.spec -mcygwin dlls/capi2032/cap20wxx.o \
libs/port/libwine_port.a -ldl -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
/usr/bin/ld: dlls/capi2032/cap20wxx.o: direct GOT relocation R_386_GOT32X against `__wine_dbg_header' without base register can not be used when making a shared object
collect2: error: ld returned 1 exit status
winegcc: /usr/bin/gcc failed
make: *** [Makefile:16025: dlls/capi2032/capi2032.dll.so] Error 2
==> ERROR: A failure occurred in build().
Aborting...
error making: wine-ge-custom
loathingkernel commented on 2021-09-24 21:37 (UTC)
@idle_zealot, you are having trouble because you edited the PKGBUILD without reading the comments.
idle_zealot commented on 2021-09-24 19:28 (UTC) (edited on 2021-09-24 19:28 (UTC) by idle_zealot)
I'm also having trouble building this.
<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
rm -f libs/port/libwine_port.a && ar rc libs/port/libwine_port.a \
libs/port/getopt.o libs/port/lstat.o libs/port/mkstemps.o libs/port/poll.o libs/port/pread.o \
libs/port/pwrite.o libs/port/readlink.o libs/port/spawn.o libs/port/symlink.o && ranlib libs/port/libwine_port.a
/home/user/.cache/yay/wine-ge-custom/src/wine-ge-custom-64-build/tools/winegcc/winegcc -o dlls/avicap32/avicap32.dll.so \
--wine-objdir . --winebuild \
/home/user/.cache/yay/wine-ge-custom/src/wine-ge-custom-64-build/tools/winebuild/winebuild -m32 \
-fno-PIC -Wl,-z,notext -fasynchronous-unwind-tables -shared \
../wine-ge-custom/wine/dlls/avicap32/avicap32.spec dlls/avicap32/avicap32_main.o \
libs/port/libwine_port.a -ldl -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
/usr/bin/ld: dlls/avicap32/avicap32_main.o: direct GOT relocation R_386_GOT32X against `__wine_dbg_header' without base register can not be used when making a shared object
collect2: error: ld returned 1 exit status
winegcc: /usr/bin/gcc failed
make: *** [Makefile:13451: dlls/avicap32/avicap32.dll.so] Error 2
==> ERROR: A failure occurred in build().
Aborting...
error making: wine-ge-custom
loathingkernel commented on 2021-09-22 23:20 (UTC)
Can't reproduce it, what version of vkd3d
are you using?
Pinned Comments
loathingkernel commented on 2022-03-02 14:12 (UTC)
@Strykar Nope, see https://aur.archlinux.org/packages/wine-ge-custom#comment-831304
You can grab compiled packages from https://github.com/loathingKernel/PKGBUILDs/releases/tag/packages
loathingkernel commented on 2021-10-15 10:01 (UTC) (edited on 2021-10-15 10:04 (UTC) by loathingkernel)
@thaewrapt, I see, you might be correct. The prebuilt package is not a good candidate for packaging for a couple of reasons. First of all, it is built using Lutris's runtime, and as such inherits the same issues as Proton, namely it is at its best when running inside that runtime. Also, although I might be wrong here, I haven't found any mention of Lutris being able to use a system-wide installation directory in the same way Steam can. For these reasons, I believe that packaging those binaries is pointless and they should be managed by Lutris itself.