Package Details: gzdoom 4.8.2-1

Git Clone URL: (read-only, click to copy)
Package Base: gzdoom
Description: Feature centric port for all Doom engine games
Upstream URL:
Licenses: GPL3, BSD, LGPL3
Replaces: gzdoom-legacy, gzdoom1
Submitter: None
Maintainer: grubber
Last Packager: grubber
Votes: 137
Popularity: 3.09
First Submitted: 2009-02-22 22:28 (UTC)
Last Updated: 2022-07-06 05:45 (UTC)

Sources (3)

Latest Comments

grubber commented on 2022-07-06 05:49 (UTC)

patlefort, added.

patlefort commented on 2022-07-05 18:27 (UTC)

Can you please add options=(!lto)? It doesn't build with lto enabled.

Mx_Sascha commented on 2022-06-21 04:11 (UTC)

Current package doesn't supply kdialog, which is required to launch the IWAD selection screen.

deathtrip commented on 2022-06-13 15:07 (UTC)

For me the package fails to build with lto enabled:
/usr/bin/ld: error: lto-wrapper failed
Disabling lto fixes the problem.

Zanthed commented on 2022-03-25 01:12 (UTC)

Hi, is it possible you can add 'aarch64' to the architectures list? ZMusic and GZDoom build and work fine on aarch64 (Arch Linux ARM) as well.

Gelmo commented on 2022-01-11 03:01 (UTC) (edited on 2022-01-11 03:34 (UTC) by Gelmo)

This package is now broken by GitHub's changes to unauthenticated requests with the git:// protocol - - This went into affect January 11, 2022

Quick fix:

sed -i 's,git://,git+https://,g' PKGBUILD
makepkg --printsrcinfo > .SRCINFO

PopeRigby commented on 2021-10-28 16:50 (UTC) (edited on 2021-11-11 01:26 (UTC) by PopeRigby)

I'm getting this when trying to update

/home/user/.cache/paru/clone/gzdoom/PKGBUILD: line 48: patch: command not found
==> ERROR: A failure occurred in prepare().
error: failed to build 'gzdoom-4.7.1-1': 
error: packages failed to build: gzdoom-4.7.1-1

EDIT: Had to clear the pacman cache pacman -Sc.

dr460nf1r3 commented on 2021-10-18 09:09 (UTC)

Cloning into 'gzdoom'... warning: You appear to have cloned an empty repository. done. fatal: invalid reference: g4.7.0

fletch2820 commented on 2021-10-18 03:12 (UTC)

No clue what the problem is. WADS have all worked in the past with GZDoom. Now when I try and open GZ, the screen just goes blank.

[bob@bob-vgnfw235j ~]$ gzdoom GZDoom g4.7.0-m - 2021-09-21 22:08:33 +0200 - SDL version Compiled on Oct 18 2021

OS: Manjaro Linux, Linux 5.13.19-2-MANJARO on x86_64 M_LoadDefaults: Load system defaults. W_Init: Init WADfiles. adding /usr/lib/gzdoom/gzdoom.pk3, 666 lumps adding /usr/lib/gzdoom/game_support.pk3, 2514 lumps adding /home/bob/.config/gzdoom/heretic.wad, 2633 lumps adding /usr/share/gzdoom/game_widescreen_gfx.pk3, 164 lumps I_Init: Setting up machine state. CPU Vendor ID: GenuineIntel Name: Intel(R) Core(TM)2 Duo CPU T5800 @ 2.00GHz Family 6, Model 15, Stepping 13 Features: SSE2 SSE3 SSSE3 HyperThreading V_Init: allocate screen. S_Init: Setting up sound. I_InitSound: Initializing OpenAL [ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1) [ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1) Opened device Built-in Audio Analog Stereo EFX enabled ST_Init: Init startup screen. Checking cmd-line parameters... S_InitData: Load sound definitions. G_ParseMapInfo: Load map definitions. Texman.Init: Init texture manager. ParseTeamInfo: Load team definitions. LoadActors: Load actor definitions. script parsing took 362.31 ms R_Init: Init Heretic refresh subsystem. DecalLibrary: Load decals. M_Init: Init menus. P_Init: Init Playloop state. ParseSBarInfo: Loading custom status bar definition. D_CheckNetGame: Checking network game status. player 1 of 1 (1 nodes) Using video driver x11

remanifest commented on 2021-09-25 21:01 (UTC)

4.7.0 required a cleanbuild for me. Install went fine after that.

SuperBart commented on 2021-09-25 01:50 (UTC)

A minor change in patch file while updating to version 4.7.0:

@@ -159,14 +155,8 @@ FGameConfigFile::FGameConfigFile ()
        SetValueForKey("Path", "$HOME/.local/share/games/doom/soundfonts", true);
        SetValueForKey("Path", "$HOME/.local/share/games/doom/fm_banks", true);
-       SetValueForKey("Path", "/usr/local/share/doom/soundfonts", true);
-       SetValueForKey("Path", "/usr/local/share/doom/fm_banks", true);
-       SetValueForKey("Path", "/usr/local/share/games/doom/soundfonts", true);
-       SetValueForKey("Path", "/usr/local/share/games/doom/fm_banks", true);
-       SetValueForKey("Path", "/usr/share/doom/soundfonts", true);
-       SetValueForKey("Path", "/usr/share/doom/fm_banks", true);
-       SetValueForKey("Path", "/usr/share/games/doom/soundfonts", true);
-       SetValueForKey("Path", "/usr/share/games/doom/fm_banks", true);
+       SetValueForKey("Path", "/usr/share/" GAMENAMELOWERCASE "/soundfonts", true);
+       SetValueForKey("Path", "/usr/share/" GAMENAMELOWERCASE "/fm_banks", true);

Because developers add something to the gameconfigfile.cpp :-P

tuxsavvy commented on 2021-08-16 15:54 (UTC)

Hi, thanks for maintaining this package. As per autumnontape said, here is a patch to rectify the need to have zmusic-git as a depends=() array:

--- PKGBUILD.orig
@@ -14,7 +14,7 @@
-         'zmusic>=1.1.1')
+         'zmusic-git')

autumnontape commented on 2021-08-06 21:47 (UTC)

The dependency on the latest zmusic should probably be part of the PKGBUILD.

grubber commented on 2021-08-03 12:48 (UTC)

simona, install the latest zmusic package

simona commented on 2021-08-03 08:37 (UTC)

/bin/ld: warning:, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/, not found (try using -rpath or -rpath-link) /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to fluid_synth_get_active_voice_count' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference tofluid_synth_pitch_bend' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to fluid_synth_set_reverb' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference tonew_fluid_synth' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to fluid_settings_setstr' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference tofluid_synth_set_reverb_on' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to fluid_synth_program_change' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference todelete_fluid_settings' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to fluid_settings_setint' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference tofluid_synth_channel_pressure' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to fluid_synth_noteoff' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference tofluid_synth_set_chorus_on' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to fluid_synth_set_interp_method' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference tofluid_synth_set_polyphony' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to fluid_synth_noteon' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference tofluid_synth_sysex' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to fluid_synth_set_chorus' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference tofluid_synth_write_float' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to delete_fluid_synth' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference tofluid_synth_get_polyphony' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to fluid_settings_getint' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference tonew_fluid_settings' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to fluid_version' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference tofluid_synth_get_cpu_load' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to fluid_synth_system_reset' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference tofluid_settings_setnum' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to fluid_synth_cc' /bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference tofluid_synth_sfload' collect2: error: ld returned 1 exit status

wantija commented on 2021-05-25 14:54 (UTC)

This is happening to me with KWin too.

annoyingduck commented on 2021-05-23 16:31 (UTC)

Tracked the MESA issue to Compiz. MESA builds after 21.0.2 with Compiz are causing GZdoom not to launch. Needs investigation elsewhere. Switching to XFWM4 works as it should. Ignore my last posts!

annoyingduck commented on 2021-05-23 13:30 (UTC)

Just updated to 4.6.0-1. Still having the same MESA issue on XFCE w/intel graphics. GZdoom will not run at all. I have to downgrade MESA to 21.0.2-1. GZdoom fires right up after downgrade. I'm not sure where else to post this.

HurricanePootis commented on 2021-05-23 01:49 (UTC)

I updated the PKGBUILD for you, and I also disabled Anon stats sending (if that's what you want)

# Maintainer: Jan Cholasta <grubber at grubber cz>
# Contributor: Christoph Zeiler <rabyte*gmail>
# Contributor: HurricanePootis <>

pkgdesc='Feature centric port for all Doom engine games'
arch=('i686' 'x86_64')
license=('BSD' 'GPL3' 'LGPL3')
makedepends=('cmake' 'desktop-file-utils' 'git')
optdepends=('blasphemer-wad: Blasphemer (free Heretic) game data'
            'chexquest3-wad: Chex Quest 3 game data'
            'doom1-wad: Doom shareware game data'
            'freedm: FreeDM game data'
            'freedoom1: Freedoom: Phase 1 game data'
            'freedoom2: Freedoom: Phase 2 game data'
            'gxmessage: crash dialog (GNOME)'
            'hacx-wad: HacX game data'
            'harmony-wad: Harmony game data'
            'heretic1-wad: Heretic shareware game data'
            'hexen1-wad: Hexen demo game data'
            'kdialog: crash dialog (KDE)'
            'strife0-wad: Strife shareware game data'
            'square1-wad: The Adventures of Square, Episode 1 game data'
            'urbanbrawl-wad: Urban Brawl: Action Doom 2 game data'
            'xorg-xmessage: crash dialog (other)')
optdepends_x86_64=('vulkan-driver: Vulkan renderer'
                   'vulkan-icd-loader: Vulkan renderer')
prepare() {
    cd gzdoom
    git submodule update --init

build() {
    cd gzdoom
    mkdir -p build
    cmake -B build \
          -D CMAKE_BUILD_TYPE=Release \
          -D CMAKE_CXX_FLAGS="${CXXFLAGS} -ffile-prefix-map=\"$PWD\"=. -DSHARE_DIR=\\\"/usr/share/gzdoom\\\"" \
          -D DYN_GTK=OFF \
          -D DYN_OPENAL=OFF \

    make -C build

package() {
    cd gzdoom
    install build/gzdoom -t "$pkgdir"/usr/bin -D
    install build/{game_support,gzdoom}.pk3 -t "$pkgdir"/usr/lib/gzdoom -D -m 644
    desktop-file-install "$srcdir"/gzdoom.desktop --dir="$pkgdir"/usr/share/applications
    install docs/{console,rh-log,skins}.* -t "$pkgdir"/usr/share/doc/gzdoom -D -m 644
    install build/{brightmaps,game_widescreen_gfx,lights}.pk3 -t "$pkgdir"/usr/share/gzdoom -D -m 644
    install build/soundfonts/gzdoom.sf2 -t "$pkgdir"/usr/share/gzdoom/soundfonts -D -m 644
    install build/fm_banks/* -t "$pkgdir"/usr/share/gzdoom/fm_banks -D -m 644
    install src/posix/zdoom.xpm "$pkgdir"/usr/share/icons/hicolor/256x256/apps/gzdoom.xpm -D -m 644
    install docs/licenses/{bsd,fxaa,gdtoa,README}.* -t "$pkgdir"/usr/share/licenses/$pkgname -D -m 644

annoyingduck commented on 2021-05-04 16:14 (UTC)

Update to my post yesterday. It's the MESA update that breaks Gzdoom. A downgrade of mesa to the last package gets Gzdoom working again for me.

annoyingduck commented on 2021-05-03 18:05 (UTC)

Anyone else able to run GZDoom after recent system updates May 03 2021? I tried rebuilding GZdoom and luck. It just won't fire up for me. Running GZdoom from the terminal brings up the iWAD selection screen then after selecting the terminal kicks back an audio error, but then seems to resolve it. When the terminal commands get to using video driver x11, the commands stop and it kills itself.

likeninja commented on 2020-12-11 18:23 (UTC)

I'm not getting the dialouge box that let's you select which IWAD to use, even though I have several in my folder.

grubber commented on 2020-11-28 07:12 (UTC)

homk, zmusic is available in AUR:

terrytuden114, did you use makepkg or some AUR helper such as yaourt?

homk commented on 2020-11-26 22:19 (UTC)

@terrytuden114 , so install it manually. Worked for me.

Anyway, you should ping zmusic developers to include the package to repository. That's not the gzdoom issue.

terrytuden114 commented on 2020-11-16 07:28 (UTC)

doesnt work fails to resolve gzmusic thanks for that

alfrednewman commented on 2020-07-26 22:37 (UTC) (edited on 2020-07-26 22:38 (UTC) by alfrednewman)

If GZDoom crashes on launch and you're using KDE, you will need to install kdialog using sudo pacman -S kdialog

It needs that to popup a window, most likely telling you it can't find a IWAD

parkerlreed commented on 2020-03-18 16:20 (UTC)

@grubber Thanks! Yeah I had a brainfart and was using git. I see where that was updated. Cheers.

grubber commented on 2020-03-17 07:48 (UTC)

parkerlreed, remove ~/.config/gzdoom/gzdoom.ini and run gzdoom again. If you are using gzdoom-git, upgrade to the latest version.

Regarding fluidsynth, gzdoom-4.3.3-2 works fine with stock fluidsynth-2.1.1-1 for me.

parkerlreed commented on 2020-03-17 02:30 (UTC)

Something is up with gzdoom right now.

Says no IWADs with them in place

strace'ing the binary points that's looking for

/usr/lib/gzdoom/game_support.pk3 or /usr/share/game_support.pk3 (Not a typo that's where it looks)

The file exists at


I had to copy that over to my local gzdoom config folder for it to be picked up. I'm not sure if this is down to a packaging or upstream issue.

Geon commented on 2020-03-08 22:38 (UTC)

@lorecast162 - I fixed it without that package. I downgraded fluidsynth from 2.1.1 to 2.1.0 with pacman and was able to play again.

lorecast162 commented on 2020-03-04 11:10 (UTC)

fluidsynth-nolibinstpatch gives 404 here on the AUR. What gives?

mutewave commented on 2020-02-24 22:50 (UTC)

Just tested without libinstpatch -- fluidsynth-nolibinstpatch works with no observed abnormalities so far. If anything changes I'll comment but so far this fixes the hanging issue

Wintershade commented on 2020-02-24 15:26 (UTC)

+1 for the fluidsynth-nolibinstpatch fix. I think this package should be set as a dependency for gzdoom.

nvllsvm commented on 2020-02-24 06:02 (UTC)

@mutewave - fluidsynth-nolibinstpatch fixes the problem for me.

mutewave commented on 2020-02-24 01:48 (UTC)

nvllsvm, i have fluidsynth 2.1.1-1 installed and am getting hangs right before gameplay as well. i saved output log. haven't tried with fluidsynth-nolibinstpatch.

nvllsvm commented on 2020-02-22 07:12 (UTC)

Looks like the fluidsynth=2.1.1-1 package is breaking the game. Hangs before gameplay.

PopeRigby commented on 2019-12-17 02:35 (UTC)

That fixed it. Thanks.

grubber commented on 2019-12-16 06:52 (UTC)

PopeRigby, remove ~/.config/gzdoom/gzdoom.ini and run gzdoom again.

PopeRigby commented on 2019-12-15 00:43 (UTC)

I'm getting "Cannot find gzdoom.pk3" when I run gzdoom

RealGecko commented on 2019-10-28 10:28 (UTC)

Yes, 4.2.3 compiled successfully, thank you!

grubber commented on 2019-10-22 09:05 (UTC)

RealGecko, thank you. I was able to reproduce the error with 4.2.1, but not with 4.2.3, so hopefully it's fixed.

RealGecko commented on 2019-10-21 11:56 (UTC)

Here's full log.

grubber commented on 2019-10-21 08:57 (UTC)

I would still like to see the failing makepkg output with make VERBOSE=1, because -lrt is a linker flag and adding it to compiler flags fixes the error just by accident. Could any of you upload it somewhere?

mydavoodeh commented on 2019-10-19 21:38 (UTC) (edited on 2019-10-19 21:45 (UTC) by mydavoodeh)

browniesrgut and RealGecko, Thanks to lobotron, I've fixed it by adding -lrt to my PKGBUILD, the var DCMAKE_CXX_FLAGS. I can confirm it's the solution to the problem.

RealGecko commented on 2019-10-18 08:21 (UTC)

-DCMAKE_EXE_LINKER_FLAGS="${LDFLAGS} -Wl,-z,noexecstack -lrt" \ This did not help.

grubber commented on 2019-10-14 08:40 (UTC)

browniesrgut, could you update the PKGBUILD to do "make VERBOSE=1" instead of just "make" and post makepkg output then?

lobotron commented on 2019-10-12 13:32 (UTC)


browniesrgut commented on 2019-10-08 21:02 (UTC) (edited on 2019-10-08 21:03 (UTC) by browniesrgut)

I added the "-lrt" argument in the PKGBUILD, still the same error.

grubber commented on 2019-10-08 19:30 (UTC)

browniesrgut, I was unable to reproduce the error, but adding -lrt to CMAKE_EXE_LINKER_FLAGS might fix it, like so:

-DCMAKE_EXE_LINKER_FLAGS="${LDFLAGS} -Wl,-z,noexecstack -lrt" \

browniesrgut commented on 2019-10-08 06:56 (UTC) (edited on 2019-10-08 06:59 (UTC) by browniesrgut)

I get this error when compiling :

Can you help me please ?

Tony556 commented on 2019-08-03 23:05 (UTC) (edited on 2019-08-04 05:45 (UTC) by Tony556)

[ 39%] Building CXX object src/CMakeFiles/zdoom.dir/posix/unix/gtk_dialogs.cpp.o
/home/tony/.cache/yay/gzdoom/src/gzdoom/src/posix/unix/gtk_dialogs.cpp:42:10: fatal error: gtk/gtk.h: No such file or directory
   42 | #include <gtk/gtk.h>
      |          ^~~~~~~~~~~
compilation terminated.

I reinstalled GTK2 and 3, and it even finds it when doing the first checks

-- Checking for module 'gtk+-3.0'
--   Found gtk+-3.0, version 3.24.10


Issue was that egl was missing, and having mesa-aco-git messed with that. Switching to base mesa fixed it.

doktorseven commented on 2019-02-25 14:26 (UTC) (edited on 2019-02-25 14:26 (UTC) by doktorseven)

Recent update to fluidsynth2 breaks fluidsynth for gzdoom.

Quick glance through source suggests src/sound/mididevices/music_fluidsynth_mididevice.cpp needs


changed to


but I haven't tested.

(my temp fix is creating symlink /usr/lib/ to /usr/lib/

Trist commented on 2019-02-18 01:53 (UTC) (edited on 2019-03-18 00:19 (UTC) by Trist)

EDIT; keeping this post here even though its stupid. I don't know exactly whats wrong, I am behind a restricted network but github itself isn't blocked and I can download archives from the site itself, yet on several occasions I get this same error (minetest-get, fsearch, etc). Its clearly isolated to my machine, maybe something about the ".git" flips a filter. Whatever, its not the packages fault

Error on build;

fatal: unable to connect to[0:]: errno=No route to host[1:]: errno=No route to host

==> ERROR: Failure while downloading gzdoom git repo Aborting...

The PKGBUILD doesn't look wrong but I tried replacing the source line with an absolute git link and removing #tag=g${pkgver} anyways, neither worked. This problem has persisted for two weeks thus far and I can download the source from the git itself so I really don't get it. Any ideas, other than to compile it manually (which im finally gunna do because im itching for doom)?

Ulukai commented on 2019-01-02 23:00 (UTC)

Build 3.7.1-2 fixes all crash issues, thanks for the quick edit!

przemko27 commented on 2019-01-02 15:02 (UTC)

In regards to the problem reported below, I shall leave this compilation guide here for those that might want it.

Ulukai commented on 2019-01-02 13:54 (UTC)

There is a problem since version 3.7.0 and 3.7.1 with the use of asmjit. It makes GZDoom crash on some occasions, see this bug report from me on the GZDoom forums. I believe the PKGBUILD needs to be updated to use GZDooms own asmjit instance instead. Can you have a look? Thanks!

Brottweiler commented on 2018-08-14 14:34 (UTC) (edited on 2018-08-14 14:34 (UTC) by Brottweiler)

==> WARNING: Package contains reference to $srcdir


SteelTitanium commented on 2018-03-27 21:48 (UTC)

There's something weird when gzdoom is compiled from AUR, P2P networking mode don't work for 3+ players, it just gets stuck on "waiting for number" with number being a random player number each time, and the client/server mode just ends up being out of sync, none of these problems are present if I download the source code from site and compile manually.

grubber commented on 2018-02-25 06:05 (UTC)

Added the fix from upstream.

DosAmp commented on 2018-02-24 15:23 (UTC) (edited on 2018-02-24 15:58 (UTC) by DosAmp)

EDIT: This has been fixed upstream (SHARE_DIR was added back) and should be included in the next version.

The issue mentioned by maxlefou also affects new installations of GZDoom without a configuration file. GZDoom 3.2.1+ no longer searchs SHARE_DIR as part of the default [FileSearch.Directories]:

stat("./gzdoom.pk3", 0x7ffdf29f8670)    = -1 ENOENT (No such file or directory)
stat("gzdoom.pk3", 0x7ffdf29f8670)      = -1 ENOENT (No such file or directory)
stat("/home/dosamp/.config/gzdoom/gzdoom.pk3", 0x7ffdf29f8670) = -1 ENOENT (No such file or directory)
stat("/usr/local/share/doom/gzdoom.pk3", 0x7ffdf29f8670) = -1 ENOENT (No such file or directory)
stat("/usr/local/share/games/doom/gzdoom.pk3", 0x7ffdf29f8670) = -1 ENOENT (No such file or directory)
stat("/usr/share/doom/gzdoom.pk3", 0x7ffdf29f8670) = -1 ENOENT (No such file or directory)
stat("/usr/share/games/doom/gzdoom.pk3", 0x7ffdf29f8670) = -1 ENOENT (No such file or directory)

The only solution for the current version is to either

  • not use the /usr/share/gzdoom directory: define INSTALL_PK3_PATH as share/doom (and SHARE_DIR as /usr/share/doom) so the GZDoom PK3 files are installed in the well known /usr/share/doom directory
  • patch src/gameconfigfile.cpp to add /usr/share/gzdoom to the list of default file search directories.

wincraft71 commented on 2018-01-23 03:43 (UTC)

openal should not be listed as an optional dependency in the PKGBUILD because it is required to hear in-game audio.

jazztickets commented on 2018-01-10 15:48 (UTC)

Looks good now, thanks.

grubber commented on 2018-01-10 06:40 (UTC)

My bad. Fixed, hopefully.

jazztickets commented on 2018-01-09 19:00 (UTC)

After every update I need to run "sudo mogrify -resize 48x48 /usr/share/icons/hicolor/48x48/apps/gzdoom.xpm"

Anyone else getting huge icons in the menus on xfce?

grubber commented on 2017-12-31 09:53 (UTC)

maxlefou, it seems you have outdated configuration, make sure /usr/share/gzdoom is listed in the [FileSearch.Directories] section in ~/.config/gzdoom/gzdoom.ini, like this:

[FileSearch.Directories] Path=~/.config/gzdoom Path=/usr/share/gzdoom Path=$DOOMWADDIR

maxlefou commented on 2017-12-30 19:59 (UTC) (edited on 2017-12-30 19:59 (UTC) by maxlefou)

Error when launching gzdoom: GZDoom g3.2.4-m - 2017-12-16 20:24:48 -0500 - SDL version Compiled on Dec 30 2017

M_LoadDefaults: Load system defaults. Cannot find gzdoom.pk3

But gzdoom.pk3 is present, in /usr/share/gzdoom

Plz fix

dmsun commented on 2017-12-18 22:41 (UTC)

hey, might want to update this to 3.2.4. Changes include some fixes to security bugs.

commented on 2017-10-07 00:36 (UTC)

Here you can find some games you might be interested in:

commented on 2017-09-14 14:25 (UTC)

Works well.

commented on 2017-05-21 21:30 (UTC)

Compilation with gcc7 fails: Can be solved by including <functional> in src/sound/oalsound.h prepare() { sed -i '3i #include <functional>' $_name/src/sound/oalsound.h }

nerflad commented on 2017-05-11 20:24 (UTC)

For those interested, I have adopted and updated the fmodex package.

spacelord commented on 2017-05-03 10:26 (UTC)

Just a FYI for those who are getting a "gzdoom.pk3 not found" with the 3.0 update: the location of gzdoom.pk3 has moved from /usr/share/games/gzdoom to /usr/share/gzdoom, so you will have to change the search path in your gzdoom.ini file.

narical commented on 2017-01-25 09:42 (UTC)

Every time I try to start new game (same error for quite a time) Compile Shader 'shaders/glsl/lineardepth.fp': 0:7(21): error: syntax error, unexpected NEW_IDENTIFIER, expecting '{'

grubber commented on 2017-01-08 16:23 (UTC)

Updated to 2.3.0. Also, I have disabled building with fmodex by default, it's not worth the hassle trying to make it work properly outside of makepkg. Everyone who had issues installing the package with your AUR frontends, it should be fixed now.

Retro_Gamer commented on 2017-01-03 04:05 (UTC) (edited on 2017-01-03 04:27 (UTC) by Retro_Gamer)

@annoyingduck, correct you are! I've had zero issues building gzdoom. Installing the 4.44.58 fmodex version works just fine and is detected and used by gzdoom. As shown in these snippets cut from my build output: ==> gzdoom dependencies: - fluidsynth (already installed) - fmodex=4.44.58 (already installed) <SNIP> ==> Continue building gzdoom ? [Y/n] Y <SNIP> -- Looking for FMOD_System_GetDriverCaps in /usr/lib/ -- Looking for FMOD_System_GetDriverCaps in /usr/lib/ - found -- Configuring done -- Generating done @GI_Jack, uninstall fmodex4.26.36 1st(it's too old to use for this now), install fmodex 4.44.58 or newer, then install or upgrade your gzoom. People are doing it this way and it's working. You can of course just as easily just comment out the fnodex dependency altogether.

ProfessorKaos64 commented on 2017-01-03 03:11 (UTC)

The regular fmodex will not work, as it only installs 4.44.58, not 4.44.62.

annoyingduck commented on 2017-01-02 16:33 (UTC)

I'm on Manjaro, I too got the fmodex dependency fail when attempting to update from previous release. The fix is simple: Install regular fmodex package from AUR, update Gzdoom, remove original fmodox4.26.36 package that previous release installed. Worked fine for me.

grubber commented on 2016-12-31 15:32 (UTC)

@GI_Jack, these are the correct dependencies. About the variables, please suggest a better way to a) deal with fmodex being incompatible between versions b) make parts of the build configurable.

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: 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.

zan commented on 2016-03-03 15:01 (UTC)

Some observations after having maintained the alternate 2.1 while waiting for the update: fmod and openal are technically optional, but without either you have no sound. Since openal is in the upstream official repos while fmod is not, I'd advocate making fmod an optdepend. You don't need to specify SHARE_DIR on cflags, it is only used on cxxflags. I'd also argue the patch to include SHARE_DIR in the iwad search path is unnecessary - you are supposed to install the main game iwads either with pacman in /usr/local?/share/games?/doom - every AUR package for an iwad uses /usr/share/doom. The extra files gzdoom uses are not iwads, they just need to be on the file search path which is what SHARE_DIR is for in the first place. Also, kdebase-kdialog is an optdepend and gzdoom will use it for its launcher if available over the gtk alternative, which should also probably be an optdepend.

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

Updated. Sorry for the delay - I rewrote the PKGBUILD, OpenAL is now supported, among other improvements and fixes.

commented on 2016-02-19 03:59 (UTC) gzdoom gzdoom1

zan commented on 2016-02-18 00:17 (UTC)

Wanted to install 2.1 on several computers so I just forked the pkg and dropped the patches here: I have notifications on so I'll delete it whenever grubber updates here.

MadTux commented on 2016-02-08 08:44 (UTC)

Do you think you could update to 2.1.0?

ozky commented on 2015-12-04 15:30 (UTC)

Yes it needed i got my own way to do it.......Builded it in seperate system and extracted it to local folder and added it to enyo doom as it can use manually added doom engine,no gtk but brutal doom and lot others get working. :)

grubber commented on 2015-11-30 19:02 (UTC)

gtk2 is required for the IWAD selection dialog and gxmessage is needed for the crash log window. Both are features I want in the build to be on par with the official Windows build, so they won't be removed, sorry.

ozky commented on 2015-11-30 18:44 (UTC) (edited on 2015-11-30 18:45 (UTC) by ozky)

You may grubber add gtk2 require as optional it's only needed to gui as without it you can use it with enyo-doom. GTK2 (optional) pacman -S --needed gcc make zlib sdl sdl2 libjpeg-turbo nasm tar bzip2 gtk2 cmake git \ fluidsynth libgme openal timidity++ mesa glu glew I compiled it with removing gtk2 and gxmessage from pkgbuild and it compiles with no error.

jclaudio commented on 2015-10-09 06:07 (UTC)

I cannot use this because of fmodex4.26.36 Anyone else having this problem?

claymore commented on 2015-03-10 16:43 (UTC)

wrong SDL lib dependency. It should be SDL2. Because of that, it does not compile out of the box.

Fincer commented on 2015-02-06 02:30 (UTC)

Thank you for informing me about the GIT version you already have available here. Well, let me clarify: The current PKGBUILD script grabs correct gzdoom version from Github. However, the problem is that if pure tar.gz archive is used, gzdoom doesn't recognize version number correctly, leading to <unknown version> issue. [fincer@fincer-laptop fincer]$ gzdoom GZDoom <unknown version> - - SDL version Compiled on Feb 6 2015 Using video driver x11 And this is what I refer to when talking about "messes with version numbering". I asked GZDoom developer Graf Zahl about this issue and he stated: "Do you have the git command line utilities installed? The broken version number suggests you have not. With this you can also retrieve the source for any branch or tag, including the release versions." Doing the installation by suggested git way gets the version number shown correctly in the program, too. Regardless of available tar.gz archives in Github. That's why I think git way is the only correct way to install this package - unless you want <unknown version> to be visible while running the program. Otherwise, the current compilation script works very fluently and builds gzdoom version 2.0.04 as suggested in the AUR package title. As you already said.

grubber commented on 2015-02-04 21:36 (UTC)

The PKGBUILD doesn't mess with anything, it uses only what is provided in the release tarball. If you want to build from git, you should use <>.

Fincer commented on 2015-02-04 00:05 (UTC)

At the moment PKGBUILD messes with GZDoom version numbering, resulting to a <unknown version>. Instead of using tar.gz package (which is presented in the current PKGBUILD file), the package must be built with git method. I corrected the PKGBUILD file for those who want the correct GZDoom version number shown when launching the program. See fixed PKGBUILD file for GZDoom 2.0.04 + all versions 1.8.5 and above here:

commented on 2014-09-25 08:22 (UTC)

If the first link for gm.sf2 is not work, use this link:

grubber commented on 2014-09-24 21:11 (UTC)

Updated to 2.0.03. See also <> for 1.8.7. zanny: You can report bugs at <>.

zan commented on 2014-09-22 01:14 (UTC)

So yeah, a lot of breakage in gz 2.0 with the Mesa drivers: By default, it is using a compatibility profile and does not recognize core profiles supporting 3.3, so it just says "get GL 3.3". If you override the Mesa version string with 3.3, it tries to use GLSL 4.0 shaders. If you use the arg -gl3 to force 3.3, it fails to compile some fragment shader. And I can't even find the gzdoom bug tracker. It isn't off their github repo and my google-fu is failing me.

commented on 2014-09-21 18:44 (UTC)

commented on 2014-09-11 17:26 (UTC)

If you want the original midi windows you can use this soundfont:

commented on 2014-09-11 09:40 (UTC)

Now I use GZdoom 1.8.6. Is ok. I created only for myself gzdoom-aur and chose version 1.8.6.

chungy commented on 2014-09-11 02:13 (UTC)

Instead of cloning the git repository, I suggest instead using${pkgver}.tar.gz in the source array, and doing "cd gzdoom-g${pkgver}" in the build() function. Should be much faster to download, and puts less strain on GitHub's servers.

commented on 2014-09-10 22:53 (UTC)

:) Unsupported OpenGL version. At least OpenGL 3.3 is required to run GZDoom. *** Fatal Error *** !!! Failed to exec debug process Segmentation fault (core dumped) I have OpenGL 3.1 :D Intel® HD Graphics 2000

commented on 2014-09-09 23:54 (UTC)

GZdoom just been updated. The stable version is 2.0.02.

grubber commented on 2014-05-25 18:50 (UTC)

Yes, but see the note about base-devel at

zan commented on 2014-05-24 10:45 (UTC)

patch is one of the dependencies of this package, since you are.. providing patches. I didn't have it until I was building gzdoom, surprisingly.

grubber commented on 2013-08-23 16:11 (UTC)

Hmm, I must have been looking at a different PKGBUILD. Mae culpa. Fixed.

miffe commented on 2013-08-14 16:24 (UTC)

@grubber: No git in makedepends, only subversion...

grubber commented on 2013-08-14 14:54 (UTC)

miffe: git already is in makedepends. larsoyvind: thanks for the heads up! Fixed.

larsoyvind commented on 2013-08-10 22:17 (UTC)

The fmod source url has changed, please update to:${_fmodver}${_fmodarch}.tar.gz

miffe commented on 2013-07-17 17:06 (UTC)

/usr/bin/makepkg: line 583: git: command not found Please add git to makedepends

z33ky commented on 2013-03-31 16:57 (UTC)

I have not had gzdoom installed before. I tried rebuilding, but that didn't fix it. I will try the zdoom forums, as I get the same problem there it seems likely that gzdoom inherits whatever is wrong from it.

grubber commented on 2013-03-31 09:02 (UTC)

I was not able to reproduce that. But it seems like if you were using gzdoom.pk3 from a different version of gzdoom.

z33ky commented on 2013-03-30 15:37 (UTC)

That fixes the paths, but the Script errors remain. Tested with The Ultimate Doom, Doom 2 and the Doom demo (doom1-wad in AUR).

grubber commented on 2013-03-30 14:31 (UTC)

It was a bug in the package(s), which caused initial config file to point at a wrong path to look for gzdoom.pk3. Remove the bad config file in ~/.config/gzdoom and gzdoom will generate a new one for you.

z33ky commented on 2013-03-28 00:19 (UTC)

$ gzdoom GZDoom v1.7.1 - SVN revision 0 - SDL version Compiled on Mar 28 2013 Using video driver x11 M_LoadDefaults: Load system defaults. Cannot find gzdoom.pk3 $ cd /usr/share/games/gzdoom $ gzdoom GZDoom v1.7.1 - SVN revision 0 - SDL version Compiled on Mar 28 2013 Using video driver x11 M_LoadDefaults: Load system defaults. Gameinfo scan took 0 ms Cannot find a game IWAD (doom.wad, doom2.wad, heretic.wad, etc.). Did you install ZDoom properly? You can do either of the following: 1. Place one or more of these wads in the same directory as ZDoom. 2. Edit your zdoom-username.ini and add the directories of your iwads to the list beneath [IWADSearch.Directories] $ DOOMWADDIR=~/.gzdoom gzdoom GZDoom v1.7.1 - SVN revision 0 - SDL version Compiled on Mar 28 2013 Using video driver x11 M_LoadDefaults: Load system defaults. Gameinfo scan took 0 ms W_Init: Init WADfiles. adding ./gzdoom.pk3, 583 lumps adding /home/z33ky/.gzdoom/doom.wad, 2306 lumps I_Init: Setting up machine state. CPU Vendor ID: GenuineIntel Name: Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz Family 6, Model 37, Stepping 2 Features: MMX SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 I_InitSound: Initializing FMOD FMOD Sound System, copyright � Firelight Technologies Pty, Ltd., 1994-2009. Loaded FMOD version 4.26.36 HOSS could not be initialized. Trying ALSA. V_Init: allocate screen. S_Init: Setting up sound. ST_Init: Init startup screen. Checking cmd-line parameters... S_InitData: Load sound definitions. G_ParseMapInfo: Load map definitions. GScript error, "gzdoom.pk3:mapinfo/doom1.txt" line 54: GUnknown property 'sucktime' found in map definition ... and lots more of those Script errors, Unknown property. In the end it won't start. The selection window does show and I selected the doom.wad, then these errors spew and that's it. Same with gzdoom-svn and zdoom. Should I take this upstream? If so, to GZDoom or ZDoom?

grubber commented on 2012-12-30 10:07 (UTC)

Fixed. I wish there was a better way of handling per-arch source files.

miffe commented on 2012-12-30 03:42 (UTC)

Fails to build since the PKGBUILD has the same md5sum for both the i686 and x86_64 version of fmod.

OrdinaryMagician commented on 2012-11-19 14:08 (UTC)

Could you please also add this fix to the svn version of the package?

grubber commented on 2012-11-07 21:38 (UTC)

Fixed. Sorry for the delay.

DullOnion commented on 2012-11-05 02:04 (UTC)

Changing the checksum from '9b1af4ae3352fbe147c72c8430df74cd' to 'b83251d0f6e06b360711b152f299ef23' in the PKGBUILD will fix that error. However, it stops compiling at 36% due to this error: [ 36%] Building CXX object src/CMakeFiles/zdoom.dir/sdl/hardware.o In file included from /tmp/yaourt-tmp/aur-gzdoom/src/gzdoom-1.6.00-build/src/gl/system/gl_system.h:94:0, from /tmp/yaourt-tmp/aur-gzdoom/src/gzdoom-1.6.00-build/src/sdl/sdlglvideo.h:7, from /tmp/yaourt-tmp/aur-gzdoom/src/gzdoom-1.6.00-build/src/sdl/hardware.cpp:48: /tmp/yaourt-tmp/aur-gzdoom/src/gzdoom-1.6.00-build/src/gl/system/gl_interface.h:206:2: error: ‘PFNGLMULTITEXCOORD2FPROC’ does not name a type /tmp/yaourt-tmp/aur-gzdoom/src/gzdoom-1.6.00-build/src/gl/system/gl_interface.h:207:2: error: ‘PFNGLMULTITEXCOORD2FVPROC’ does not name a type make[2]: *** [src/CMakeFiles/zdoom.dir/sdl/hardware.o] Error 1 make[1]: *** [src/CMakeFiles/zdoom.dir/all] Error 2 make: *** [all] Error 2

commented on 2012-11-04 06:42 (UTC)

I get the same error as ZeroKnight unfortunately.

ZeroKnight commented on 2012-10-17 21:36 (UTC)

==> Validating source files with md5sums... fmodapi43818linux64.tar.gz ... FAILED gzdoom-1.6.00-sharedir.patch ... Passed gzdoom.desktop ... Passed ==> ERROR: One or more files did not pass the validity check!

grubber commented on 2010-07-31 13:30 (UTC)

It might be a driver problem, or the feature simply isn't implemented for Linux. Better ask at the GZDoom forum. (

jackoneill commented on 2010-07-31 11:00 (UTC)

Does the F11 key (gamma correction) have any effect for you guys? It doesn't do anything on my system. I see the messages at the top of the screen with the increasing value (between 1 and 3), but it has no effect on the image. What could be the problem?

grubber commented on 2010-07-29 08:41 (UTC)

Sorry. Fixed.

miffe commented on 2010-07-29 01:57 (UTC)

fmodapi42816linux.tar.gz fails the md5sum check.

grubber commented on 2010-07-27 17:49 (UTC)

Updated. Included fmodex lib in the package, as it's not API compatible between versions and updates to the fmodex package (which is now in the community repo) break compilation/sound in gzdoom. Also cleaned up the PKGBUILD and fixed all errors reported by namcap.

jackoneill commented on 2010-05-22 16:19 (UTC)

The build fails at around 88% with this error: "/tmp/clyde-asdf/gzdoom/gzdoom/src/gzdoom-1.4.08-build/src/sound/fmodsound.cpp:170:23: error: ‘FMOD_OUTPUTTYPE_SOUNDMANAGER’ was not declared in this scope" Downgrading fmodex from 4.30.02 to 4.28.13 fixed it for me.

grubber commented on 2010-04-24 09:13 (UTC)


Ulukai commented on 2010-04-23 12:31 (UTC)

Will this package be updated to the latest version please?