Page 32 of 54
Re: The official "ZDoom on Linux" thread.
Posted: Tue Dec 14, 2010 6:45 am
by Gez
Question to all Linux (and Mac) users: do you get the IWAD selection box when starting ZDoom? Does the "queryiwad" console variable work?
I'm just wondering if there is a reason why [wiki=Miscellaneous_options#queryiwad]this menu entry[/wiki] is filtered to be Windows only. Because as far as I know, there's a GTK implementation of that widget for Linux, and an Objective-C version for Mac.
Re: The official "ZDoom on Linux" thread.
Posted: Tue Dec 14, 2010 9:39 am
by Siggi
Gez wrote:Question to all Linux (and Mac) users: do you get the IWAD selection box when starting ZDoom? Does the "queryiwad" console command work?
Seems to work for me in linux. Though 'queryiwad' doesn't seem to be a command. (edit: but it does what it's supposed to)
Re: The official "ZDoom on Linux" thread.
Posted: Tue Dec 14, 2010 10:01 am
by Blzut3
Gez wrote:Question to all Linux (and Mac) users: do you get the IWAD selection box when starting ZDoom? Does the "queryiwad" console command work?
I'm just wondering if there is a reason why [wiki=HUD_options#queryiwad]this menu entry[/wiki] is filtered to be Windows only. Because as far as I know, there's a GTK implementation of that widget for Linux, and an Objective-C version for Mac.
Yes there is and the queryiwad variable does work. I actually noticed this about a week ago but forgot to actually fix it.
Re: The official "ZDoom on Linux" thread.
Posted: Wed Dec 15, 2010 12:28 am
by Virii
Chris wrote:I would recommend getting the version recommended in the wiki directly from FMOD's site, and extracting it into the fmod/ sub-directory of ZDoom's directory (so you get, eg, zdoom/fmod/api/lib/libfmodex*.so)
Is this the correct entry?
cmake -DCMAKE_BUILD_TYPE=Release -DFMOD_LIBRARY=/zdoom/fmod/api/lib/libfmodex*.so
Re: The official "ZDoom on Linux" thread.
Posted: Wed Dec 15, 2010 12:32 am
by Chris
Virii wrote:Is this the correct entry?
cmake -DCMAKE_BUILD_TYPE=Release -DFMOD_LIBRARY=/zdoom/fmod/api/lib/libfmodex*.so
No, ZDoom will find it automatically. Just run
Code: Select all
cmake .. -DCMAKE_BUILD_TYPE=Release
where ../CMakeLists.txt and ../fmod/api and such extist.
Re: The official "ZDoom on Linux" thread.
Posted: Wed Dec 15, 2010 7:14 am
by Virii
No, ZDoom will find it automatically.
Okay. I can see the from the output that it found the location of fmodex.
But...when I go to run the compiled ZDoom, this is what I get:
*** Fatal Error ***
Illegal operand (signal 4)
Address: 0x8545e1b
System: Linux MY-PC 2.6.36-ARCH #1 SMP PREEMPT Fri Dec 10 20:01:53 UTC 2010 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux
GCC version: 4.5.1
ZDoom version 2.5.0 (r3040) (Dec 15 2010)
Command line: ./zdoom -iwad /media/games/DOOM_SE/DOOM.WAD
Wad 0: zdoom.pk3
Wad 1: DOOM.WAD
Current map: E1M1
viewx = 69206016
viewy = -236978176
viewz = 2686976
viewangle = 40000000
Executing: gdb --quiet --batch --command=gdb-respfile-EKaaUw --pid=4739
Re: The official "ZDoom on Linux" thread.
Posted: Wed Dec 15, 2010 10:40 am
by Chris
It doesn't output anything more than that? Do you have GDB installed?
Re: The official "ZDoom on Linux" thread.
Posted: Wed Dec 15, 2010 8:08 pm
by Virii
Okay. I installed the package, and ran zdoom again. It crashes only when attempting to load a map, and I can navigate the main menu.
The terminal appeared to be hanging, so after about 15 minutes, I canceled the action. The attached log is the result. By the way, this is my attempt on Arch, instead of the Debian system from a few posts back. Funnily enough after installing the ZDoom packages from the AUR build system, I get the same error as compiling it traditionally. It crashed when attempting to start a episode from the main menu.
Re: The official "ZDoom on Linux" thread.
Posted: Thu Dec 16, 2010 3:01 am
by Chris
That unfortunately gives no backtrace. Build it in Debug mode instead of Release (and make sure it all gets rebuilt).
Re: The official "ZDoom on Linux" thread.
Posted: Thu Dec 16, 2010 9:38 pm
by Virii
I rebuilt ZDoom as debug from then last stable
(?) version
(2.5.0-1) instead of the SVN, so I'm assuming it must be my PC's hardware setup.
I ran the command 'gdb zdoom', set the log text name, and started ZDoom. Unfortunately, the x session I'm running it in hangs like before. I ended canceling the now frozen X after about 30 minutes.
Here's the contents of the log:
Starting program: /root/zdoom/debug/zdoom -iwad /media/games/DOOM_SE/DOOM.WAD
[Thread debugging using libthread_db enabled]
[New Thread 0xb6cdab70 (LWP 1255)]
[New Thread 0xb64d9b70 (LWP 1256)]
[New Thread 0xb5cd8b70 (LWP 1257)]
Program received signal SIGILL, Illegal instruction.
0x0853f79b in dsm8 ()
Hangup detected on fd 0
error detected on stdin
A debugging session is active.
Inferior 1 [process 1252] will be killed.
Quit anyway? (y or n) EOF [assumed Y]
Re: The official "ZDoom on Linux" thread.
Posted: Fri Dec 17, 2010 7:48 am
by Chris
Try applying this patch:
http://forum.zdoom.org/viewtopic.php?f= ... 55#p536876
And run the debug build normally (outside of gdb, othewrwise input may get locked). When ZDoom crashes, it will automatically run gdb and dump out a crash log.
You should also try to use the latest SVN, just to make sure the problem hasn't been inadvertently fixed.
Re: The official "ZDoom on Linux" thread.
Posted: Sat Dec 18, 2010 9:57 pm
by Virii
I ended up rebuilding the SVN as debug. Here's the result:
http://pastebin.com/aBTPAfZH
I ended up canceling it after about 45 minutes as it appeared to be frozen.
EDIT:
How do I apply the patch? I've installed the patch package. Do I just run it from the SVN's top directory?
Re: The official "ZDoom on Linux" thread.
Posted: Sat Dec 18, 2010 11:08 pm
by Chris
From the top directory (where CMakeLists.txt is), run
Then build and ZDoom again.
Re: The official "ZDoom on Linux" thread.
Posted: Sun Dec 19, 2010 6:26 am
by Remmirath
Since I pretty much have the same problem, I did that, and here's the crash log.
Re: The official "ZDoom on Linux" thread.
Posted: Sun Dec 19, 2010 2:00 pm
by Chris
Hmm. It seems it's crashing in the texture mapping assembly code. Somewhere around the dsm8 label, it looks like. I can't say how accurate that is, but the backtraces do show that it's in 'dsm8' right before the signal handler is called. You could try seeing if it works if you disable assembly (pass -DNO_ASM=1 to cmake).
