Package Details: gzdoom 4.14.0-1

Git Clone URL: https://aur.archlinux.org/gzdoom.git (read-only, click to copy)
Package Base: gzdoom
Description: Feature centric port for all Doom engine games
Upstream URL: http://www.zdoom.org/
Licenses: GPL3, BSD, LGPL3
Replaces: gzdoom-legacy, gzdoom1
Submitter: None
Maintainer: xente
Last Packager: xente
Votes: 167
Popularity: 2.25
First Submitted: 2009-02-22 22:28 (UTC)
Last Updated: 2024-12-18 19:14 (UTC)

Dependencies (27)

Sources (4)

Latest Comments

« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 14 15 16 17 Next › Last »

GI_Jack commented on 2016-12-31 13:29 (UTC)

please fix the dependencies Proceed with installation? [Y/n] y error: package 'fmodex' was not found Edit gzdoom PKGBUILD with $EDITOR? [Y/n] y error: package 'fmodex' was not found error: package 'fmodex' was not found depends=('fluidsynth' ${_fmodex:+$(LC_ALL=C pacman -Q $_fmodex | sed -r 's/ /=/;s/-.*$//')} 'gtk2' 'libgl' 'libgme' ${_openal:+'libsndfile'} ${_openal:+'mpg123'} ${_openal} 'sdl2' ) What the fuck is that happy horse shit?, there is no need for variablized deps.

grubber commented on 2016-12-29 14:48 (UTC)

@Flisk, the segfault should be fixed now that the last fmodex version is used by default. @notuxius, works for me, try updating your fmodex package to 4.44.62.

Flisk commented on 2016-12-28 06:04 (UTC)

@grubber That's what I do already. I was wondering if other people were having problems with Fmod-enabled builds. If that were the case, it would make sense to disable it by default. Doesn't seem like anyone is having this problem (have you tried reproducing it?), and I'm not interested in pinpointing the exact cause when builds without Fmod work fine.

notuxius commented on 2016-12-27 18:35 (UTC) (edited on 2016-12-27 18:51 (UTC) by notuxius)

@grubber error on build: :: resolving dependencies... :: no results found for fmodex=4.44.62

grubber commented on 2016-12-14 17:20 (UTC)

Why by default? You can easily disable it yourself in the PKGBUILD.

Flisk commented on 2016-11-25 00:33 (UTC)

Are there any reasons not to disable fmodex by default? I'm currently getting segfaults when discovering secrets on fmodex-enabled builds, and the problem goes away when I build without fmod. Am I alone with that issue?

allcaps commented on 2016-03-05 08:13 (UTC) (edited on 2016-03-05 08:13 (UTC) by allcaps)

The fmodex version this requires is not available by the standard fmodex AUR entry. There's one named differently here: https://aur.archlinux.org/packages/fmodex4.26.36 that is the exact version needed. If you replace the fmodex entry at the top of the pkgbuild with that one instead this builds and works fine, sound and all.

zan commented on 2016-03-04 02:08 (UTC) (edited on 2016-03-04 02:09 (UTC) by zan)

Note that kdialog replaces gxmessage (it is the kde xmessage implementation), so only one or the other is required.

grubber commented on 2016-03-03 21:07 (UTC)

Fmodex can't be an optdepend - optdepends are for *runtime* optional dependencies, but fmodex is a *build-time* optional dependency - if you build the package with fmodex, the gzdoom binary will be linked to libfmodex, so uninstalling it would break the binary, which is not correct. You can choose whether to build with or without fmodex using the _fmodex variable at the top of the PKGBUILD, ditto for openal. There is no harm in defining SHARE_DIR in CFLAGS and it keeps CFLAGS consistent with CXXFLAGS. The SHARE_DIR patch is there to support the IWAD symlinks included in the package, which are there so you can put retail IWADs to your user IWAD directory without hiding IWADs of the same name provided by the freedoom and hexen1-wad packages. I suppose putting the symlinks into the libdir should work equally well, which would obsolete the patch. Didn't know about kdialog, will fix.

« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 14 15 16 17 Next › Last »