The official "ZDoom on Linux" thread.

[niculinux]

hello there!

since 1 yera I'm a linux user...but very newbie..so I was just thinking:

It is possible to make portable zdoom/gzdoom versions? So you just unzip the files in a directory, execute the binary files et voilà.. that should also useful to bring even more doomers to linux, I think...

[Blzut3]

On Linux based operating systems the "portable" method of installation is unusual. It can be done, but you're going to make your life a lot harder trying. If you are using a debian based distribution you can install ZDoom and GZDoom though a package repository: http://debian.drdteam.org/

If you really want a portable installation so you can run it off a USB drive on that one other Linux based computer you come across, then you'll need to create a shell script that sets a few parameters like so:

Code: Select all

#!/bin/bash
./zdoom -shotdir . -config ./zdoom.ini -savedir . $*

The Linux/Mac filesystem is designed so that you're entire user profile (settings for all programs and personal files) can be portable, not individual applications.

[Edward-san]

Not always you can make the application portable if different versions of the compiler are used.

For example, if you compile zdoom with a version of g++ higher than 4.5 then you can't run the game with an older libstdc++, because of the missing `GLIBCXX_3.4.15' in the library.

[Mannequin]

On Linux based operating systems the "portable" method of installation is unusual. It can be done, but you're going to make your life a lot harder trying. If you are using a debian based distribution you can install ZDoom and GZDoom though a package repository: http://debian.drdteam.org/

How up-to-date is ZDoom on this repository? Does it build the latest revision on a daily (or insert some other time frame here) basis?

-M.

[Blzut3]

I build the latest stable. If there starts to become like a year between a release then I sneak in an SVN revision since the stable is "uselessly old."

[zdoomer]

Any way to change cfg folder to /opt ?

[Blzut3]

Not sure why you want to, but you can do that with -config.

[marver0ps]

i always get this when i use the make command

Code: Select all

[ 86%] /usr/bin/cmake: /usr/local/lib/libz.so.1: no version information available (required by /usr/lib/x86_64-linux-gnu/libxml2.so.2)
Building CXX object src/CMakeFiles/zdoom.dir/sound/fmodsound.o
/home/daniel/trunk/src/sound/fmodsound.cpp:201:19: error: ‘FMOD_SPEAKERMODE_PROLOGIC’ was not declared in this scope
make[2]: *** [src/CMakeFiles/zdoom.dir/sound/fmodsound.o] Error 1
make[1]: *** [src/CMakeFiles/zdoom.dir/all] Error 2
make: *** [all] Error 2

[Blzut3]

I assume you haven't compiled before? You probably are trying to use an unsupported version of fmod.

[Edward-san]

Hmm, I'm trying to compile zdoom scripting branch but it seems cmake doesn't generate zcc-parse.c/h... I don't know why.

[yoshi314]

perhaps it's the better topic to post it, but i cannot build non-SSE zdoom with current svn, i've posted it here :

http://forum.zdoom.org/viewtopic.php?f=2&t=35154

does anyone have any suggestion on how to fix it ?

[Blzut3]

You can remove the if statement near the line that it's erroring out on and then it should compile fine. I guess the real question is though, why are you compiling without SSE? ZDoom checks the processor flags to determine if SSE can be executed and then falls back to the slower code if not.

[yoshi314]

You can remove the if statement near the line that it's erroring out on and then it should compile fine. I guess the real question is though, why are you compiling without SSE? ZDoom checks the processor flags to determine if SSE can be executed and then falls back to the slower code if not.

i assumed that SSE option forces SSE code on, not enables sse autodetection in zdoom. i'd like to be corrected on this by someone in the know.

i am packaging zdoom for tiny core linux, and a rule of thumb is to build software for lowest common denominator platform, and optionally provide separate package dedicated for faster cpus. this is why i am making sure i can get a build valid for sse-incapable x86 cpus. if zdoom has sse autodetection - that's good news for me.

[Blzut3]

Well I'm a developer, so I should know something. ZDoom has CPUID reading code. The code that fails to compile looks like this:

Code: Select all

	if (CPU.bSSE2)
	{
		func = ClassifyLineSSE2;
		diff = int((char *)ClassifyLineSSE2 - (char *)calleroffset);
	}
	else
	{
		func = ClassifyLine2;
		diff = int((char *)ClassifyLine2 - (char *)calleroffset);
	}

Granted the bug you reported should be fixed, but the normal compile should be fine for your case. The main reason ZDoom has a compile without SSE option is for non-x86 CPUs.

The only reason I'm not fixing this bug myself is I'm not sure if I should be #ifdefing that piece of code or if compiling without SSE should imply BACKPATCH should be disabled as well. (The code in question is modifying the function call so that future calls go directly to the SSE/nonSSE function after the first call.)

[yoshi314]

thanks for clarification, i'll go with sse=on build then, as i need plain x86 binary.

some other things i stumbled upon :

- i cannot change SHARE_DIR through variables (or CFLAGS="$CFLAGS -DSHARE_DIR=\"...\" " ), for some reason. i have to patch that in source code. what am i doing wrong ?

- fluidsynth soundfont path seems to be hardcoded in the sources (on linux), is there a reason it's this way ? perhaps it could be adjusted through cmake vars at build time (or maybe a config file entry) ?