The official "ZDoom on Linux" thread.
Moderators: GZDoom Developers, Raze Developers
Forum rules
Please don't start threads here asking for help. This forum is not for requesting guides, only for posting them. If you need help, the Editing forum is for you.
Please don't start threads here asking for help. This forum is not for requesting guides, only for posting them. If you need help, the Editing forum is for you.
Re: The official "ZDoom on Linux" thread.
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...
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...
-
-
- Posts: 3144
- Joined: Wed Nov 24, 2004 12:59 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Contact:
Re: The official "ZDoom on Linux" thread.
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:
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.
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 . $*
-
- Posts: 1774
- Joined: Sat Oct 17, 2009 9:40 am
Re: The official "ZDoom on Linux" thread.
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.
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.
Re: The official "ZDoom on Linux" thread.
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?Blzut3 wrote: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/
-M.
-
-
- Posts: 3144
- Joined: Wed Nov 24, 2004 12:59 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Contact:
Re: The official "ZDoom on Linux" thread.
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."
Re: The official "ZDoom on Linux" thread.
Any way to change cfg folder to /opt ?
-
-
- Posts: 3144
- Joined: Wed Nov 24, 2004 12:59 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Contact:
Re: The official "ZDoom on Linux" thread.
Not sure why you want to, but you can do that with -config.
Re: The official "ZDoom on Linux" thread.
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
-
-
- Posts: 3144
- Joined: Wed Nov 24, 2004 12:59 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Contact:
Re: The official "ZDoom on Linux" thread.
I assume you haven't compiled before? You probably are trying to use an unsupported version of fmod.
-
- Posts: 1774
- Joined: Sat Oct 17, 2009 9:40 am
Re: The official "ZDoom on Linux" thread.
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.
Re: The official "ZDoom on Linux" thread.
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 ?
http://forum.zdoom.org/viewtopic.php?f=2&t=35154
does anyone have any suggestion on how to fix it ?
-
-
- Posts: 3144
- Joined: Wed Nov 24, 2004 12:59 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Contact:
Re: The official "ZDoom on Linux" thread.
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.
Re: The official "ZDoom on Linux" thread.
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.Blzut3 wrote: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 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.
-
-
- Posts: 3144
- Joined: Wed Nov 24, 2004 12:59 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Contact:
Re: The official "ZDoom on Linux" thread.
Well I'm a developer, so I should know something. ZDoom has CPUID reading code. The code that fails to compile looks like this:
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.)
Code: Select all
if (CPU.bSSE2)
{
func = ClassifyLineSSE2;
diff = int((char *)ClassifyLineSSE2 - (char *)calleroffset);
}
else
{
func = ClassifyLine2;
diff = int((char *)ClassifyLine2 - (char *)calleroffset);
}
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.)
Re: The official "ZDoom on Linux" thread.
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) ?
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) ?