The official "ZDoom on Linux" thread.

Discuss anything ZDoom-related that doesn't fall into one of the other categories.

Postby Siggi » Tue Aug 08, 2006 11:12 am

Build needs a mention in the licence, as its licence does get shipped with ZDoom.
User avatar
Siggi
 
Joined: 03 Oct 2004
Location: South Africa

Postby Jim » Tue Aug 08, 2006 11:51 am

The basic gist of the mish-mash of licenses for ZDoom code is that the code, as a whole, is for non-commericial use only.
User avatar
Jim
By the Power of Grayskull...I have the Source Code!
 
Joined: 11 Aug 2003

Postby Krillancello » Tue Aug 08, 2006 1:02 pm

Maybe the license should be renamed to "ZDoom License" and added to the Wiki (as I haven't seen it there as of yet).

scen: The ebuild works fine. :o I just had to make Portage ignore the ~x86 and then --digest it.

Now I wonder if we can setup some ebuilds for ACC, ZDBSP and ZETH. :lol:
User avatar
Krillancello
LWM is My Hero
 
Joined: 27 Nov 2004
Location: Teh Intarwebivurs

Postby scen » Tue Aug 08, 2006 3:19 pm

Krillancello wrote:scen: The ebuild works fine. :o I just had to make Portage ignore the ~x86 and then --digest it.

Very good :twisted: Keep in mindit that isn't the final version, next week i'll submit an updated version on Gentoo Bugzilla
Krillancello wrote:Now I wonder if we can setup some ebuilds for ACC, ZDBSP and ZETH. :lol:

I thinks it would be quite simple, If i have some spare time i'll try to make them.
User avatar
scen
Doomed forever
 
Joined: 08 Aug 2006
Location: Padova, Italy

Postby Bio Hazard » Tue Aug 08, 2006 3:48 pm

Perhaps those should all be under ZDoomUtils?

Everything in the editing package plus ACC and ZDBSP should compile fine. Perhaps throw all those into a single ebuild? Maybe ACC and ZDBSP together (ZDoomUtils) and the other stuff seperate (ZDoomOldUtils)?
User avatar
Bio Hazard
Lord of the Lord of Nitpicking.
 
Joined: 15 Aug 2003
Location: ferret ~/C/ZDL $

Postby Krillancello » Tue Aug 08, 2006 3:55 pm

Bio: They do compile, as I had done so before. Also, I personally would just rather have acc and zdbsp separate, but that's just my opinion.
User avatar
Krillancello
LWM is My Hero
 
Joined: 27 Nov 2004
Location: Teh Intarwebivurs

Questions about compiling from source in Linux

Postby scen » Fri Aug 11, 2006 3:26 am

Some question for ZDoom devs:

I'm making an ZDoom ebuild for Gentoo Linux, where almost every package is installed (and compiled, of course) from source.
  • is it safe to change CFLAGS in default Makefile.linux?

    With default configuration they're set to:
    Code: Select allExpand view
    without DEBUG:
    -pipe -Wall -Wno-unused -fno-strict-aliasing -O2 -fomit-frame-pointer -MMD -DHAVE_FILELENGTH -D__forceinline=inline -Izlib -IFLAC `sdl-config --cflags` -Dstricmp=strcasecmp -Dstrnicmp=strncasecmp -DNEED_STRUPR

    with DEBUG:
    -pipe -Wall -Wno-unused -fno-strict-aliasing -MMD -DHAVE_FILELENGTH -D__forceinline=inline -Izlib -IFLAC `sdl-config --cflags` -Dstricmp=strcasecmp -Dstrnicmp=strncasecmp -DNEED_STRUPR
     -D_DEBUG -g3


    In this ebuild i want to substitute them with global CFLAGS set in Gentoo installation (in /etc/make.conf); for example, in my home linux system they ar -march i686 -O2 -pipe.e

    What are the "indispensable" CFLAGS (i think -Izlib -IFLAC `sdl-config --cflags` )?
  • Is it possible to make more "verbose" the compilation output (instead of elegant but somewhat useless "compiling abcde.foo [OK]" output style...) :P


Thanks in advance for any explanation :)
User avatar
scen
Doomed forever
 
Joined: 08 Aug 2006
Location: Padova, Italy

Postby Bio Hazard » Fri Aug 11, 2006 9:19 am

You could probably just append the global CFLAGS to the makefile CFLAGS.
About the compiling, just don't run it through CDDV. (If you don't, don't bother compiling cddv)
User avatar
Bio Hazard
Lord of the Lord of Nitpicking.
 
Joined: 15 Aug 2003
Location: ferret ~/C/ZDL $

Postby Siggi » Sun Aug 27, 2006 5:24 am

I'd like a little help compiling ZDoom. I've done it before, so I'm sure it's not a 2.1.4 bug.
The output I'm getting is:
Code: Select allExpand view
make -C tools/updaterevision
make[1]: Entering directory `/home/player1/zdoomsrc/tools/updaterevision'
gcc -Os -Wall -fomit-frame-pointer   -c -o updaterevision.o updaterevision.c
Linking updaterevision:                                               [OK]     
updaterevision.o: In function `main':updaterevision.c:(.text+0x5e): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
make[1]: Leaving directory `/home/player1/zdoomsrc/tools/updaterevision'
sh: svnversion: command not found
mkdir releaseobj
Assembling a.nas:                                                     [OK]     
Assembling misc.nas:                                                  [OK]     
Assembling tmap2.nas:                                                 [OK]     
Assembling tmap3.nas:                                                 [OK]     
Assembling tmap.nas:                                                  [OK]     
Compiling am_map.cpp:                                                 [ERROR] 
g++ -fno-rtti -pipe -Wall -Wno-unused -fno-strict-aliasing -O2 -fomit-frame-pointer -MMD -DHAVE_FILELENGTH -D__forceinline=inline -Izlib -IFLAC -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -Dstricmp=strcasecmp -Dstrnicmp=strncasecmp -DNEED_STRUPR -Isrc/ -Isrc/g_doom/ -Isrc/g_heretic/ -Isrc/g_hexen/ -Isrc/g_raven/ -Isrc/g_shared/ -Isrc/g_strife/ -Isrc/oplsynth/ -Isrc/sound/ -Isrc/sdl/ -DUSEASM=1 -DNDEBUG -o releaseobj/am_map.o -c src/am_map.cpp
================================================================================src/am_map.cpp: In function ‘BOOL AM_clipMline(mline_t*, fline_t*)’:
src/am_map.cpp:1153: warning: ‘tmp$x’ may be used uninitialized in this function
src/am_map.cpp:1153: warning: ‘tmp$y’ may be used uninitialized in this function
{standard input}: Assembler messages:
{standard input}:141: Error: Incorrect register `%rcx' used with `l' suffix
{standard input}:176: Error: Incorrect register `%rdi' used with `l' suffix
{standard input}:484: Error: Incorrect register `%rcx' used with `l' suffix
{standard input}:497: Error: Incorrect register `%r8' used with `l' suffix
{standard input}:509: Error: Incorrect register `%r8' used with `l' suffix
{standard input}:520: Error: Incorrect register `%r8' used with `l' suffix
{standard input}:531: Error: Incorrect register `%rdi' used with `l' suffix
{standard input}:583: Error: Incorrect register `%rcx' used with `l' suffix
{standard input}:617: Error: Incorrect register `%rcx' used with `l' suffix
{standard input}:663: Error: Incorrect register `%rcx' used with `l' suffix
{standard input}:4958: Error: Incorrect register `%rcx' used with `l' suffix
{standard input}:4959: Error: Incorrect register `%r9' used with `l' suffix
{standard input}:4968: Error: Incorrect register `%rdx' used with `l' suffix
{standard input}:4969: Error: Incorrect register `%rcx' used with `l' suffix
make: *** [releaseobj/am_map.o] Error 1

I'm trying to compile from "zdoom-2.1.4-src.7z" on Ubuntu 6.06 LTS 64bit.
I'm guessing the problem is I have not installed something which should be installed.
User avatar
Siggi
 
Joined: 03 Oct 2004
Location: South Africa

Postby Grubber » Sun Aug 27, 2006 5:31 am

64bit is the problem I think.
User avatar
Grubber
I can wire anything directly into anything. I am the professor!
 
Joined: 15 Oct 2003
Location: Czech Republic

Postby Jim » Sun Aug 27, 2006 12:33 pm

Until 64-bit compilation is fixed, you can install the 32-bit libs and compile using -m32 in your CFLAGS.
User avatar
Jim
By the Power of Grayskull...I have the Source Code!
 
Joined: 11 Aug 2003

Postby Siggi » Sun Aug 27, 2006 1:01 pm

I don't really feel like breaking linux, and I've done it once this weekend already :wink:

Would I just download the 32bit packages and install them as normal, or would I have to do it in a way which doesn't harm my 64bit libs? (I'm still new to this :))
User avatar
Siggi
 
Joined: 03 Oct 2004
Location: South Africa

Postby Jim » Sun Aug 27, 2006 1:27 pm

First of all, let me state that I don't use and haven't ever used Ubuntu or anything Debian-based and don't have a 64-bit processor. That said, here is what I think you have to do:
Code: Select allExpand view
sudo aptget install ia32-libs ia32-libs-dev linux32

If they don't install, you have to enable installing from the "Universe" and possibly the "Multiverse" in Synaptic as describe here.
Then, once you compile zdoom using -m32, you can run it (and similarly for any other 32-bit Linux application) like so:
Code: Select allExpand view
linux32 zdoom

Lastly, this won't break you install. (Forcing the regular 32-bit libs to install over the 64-bit libs would, though.) The 32-bit libs will install alongside the 64-bit libs. They will only be used by gcc with the -m32 switch and by applications when they are run via linux32.

BTW, using 32-bit libs on a 64-bit architecture is much easier and better supported at the moment using an rpm-based distribution, especially SuSE.
User avatar
Jim
By the Power of Grayskull...I have the Source Code!
 
Joined: 11 Aug 2003

Postby Siggi » Sun Aug 27, 2006 1:42 pm

Thank you very much. :)
I actually didn't understand fully what you meant when you said I should install the 32bit libs, so it's a good thing I asked before trying myself. I haven't gone as far as compiling yet, but I've found everything I need. Thanks again.
User avatar
Siggi
 
Joined: 03 Oct 2004
Location: South Africa

Postby Graf Zahl » Mon Aug 28, 2006 3:18 am

Jim wrote:Until 64-bit compilation is fixed...



That will require a lot of work because ZDoom's DWORD and SDWORD types are longs, not ints. Maybe these type definitions should be replaced with the new standard intxx_t/uintxx_t types...
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

PreviousNext

Return to General

Who is online

Users browsing this forum: No registered users and 5 guests