Compiling a mod under GNU/Linux


(WalterBennet) #1

I am running GNU/Linux and I have downloaded the ET source today (which was a win32 executable so I had to use wine :() I have changed some stuff in the code, but how do I compile it? There is no Makefile, not even in the “unix” directory.

Thank you in advance.


(MindLink) #2

in the unix directory there’s a file called “cons” … that’s a perl construct script which is kind of similar to a make. mark that file as executable, edit it, have the first line point at your perl directory, then execute it using either
./cons – release ( if you use a gcc < 3.0 )
or
./cons – release gcc3 ( if you use a gcc > 3.0 )
Cheers

PS.: don’t forget the space between – and release :wink:


(WalterBennet) #3

What do you mean with “perl directory”? I put “#!/usr/bin/env /usr/lib/perl5/5.8.0” as the command interpreter in the “cons” script, but I get:
: No such file or directory5/5.8.0

Sorry for the questions, but I have never used perl before. I only have experience with C/C++ (and a little bit of experience with make).


(MindLink) #4

enter

./which perl

that should give you your perl working directory, in most cases that will be /usr/bin/perl so your first line in the cons script will look like the following

#!/usr/bin/perl


(WalterBennet) #5

I tried that, but it gives me a “bad interpreter” error.


(MindLink) #6

ok that means the directory you’ve given was incorrect.
are you sure you entered the path returned to you by the “which perl” statement?
you also might want to try the standard line

#!/usr/bin/env perl

though that won’t work on every system.
What Linux distribution are you using btw.?


(WalterBennet) #7

Yes, I copied and pasted it. And the standard line doesn’t work either :frowning:
I am using Gentoo.


(MindLink) #8

Uh Gentoo brr… :wink: Have no experience with that one. I know a friend of mine got the source to compile using GenToo, don’t know which problems he encountered though (but I’m pretty sure there were some). Gonna ask him when I see him again.
Both versions gave the same “bad interpreter” error?
Mh… What did “which perl” return to you as directory?


(TTimo) #9

Bad interpreter error might just be a CRLF issue. Make sure you unzip with -a to get all the files in unix format.


(WalterBennet) #10

Ok, I extracted the code again and change the intepreter to /usr/bin/perl (I typed it myself this time) and now suddenly it seems to work (it’s compiling something at the moment).
I dont know why I didn’t work before, I simply copied and paste the output of “which perl” (i.e. /usr/bin/perl) :???:

Sorry for wasting your time


(MindLink) #11

np, thats what this forum is for :slight_smile: good to see that it works fine now. :slight_smile:


(Leff) #12

release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c: In function __declspec': release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:836: syntax error before{’
release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:838: storage class specified for parameter Ljmptab' release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:840: syntax error before__asm’
release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:1094: syntax error before for' release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:1347: storage class specified for parametersr’
release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:1347: storage class specified for parameter sp' release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:1347: storage class specified for parametersy’
release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:1347: storage class specified for parameter cr' release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:1347: storage class specified for parametercp’
release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:1347: storage class specified for parameter cy' release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:1350: syntax error beforeangle’
release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:1389: parameter minelem' is initialized release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:1395: syntax error beforefor’
release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:1465: syntax error before (' release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:1490: redeclaration ofj’
release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:1463: j' previously declared here release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.c:1492: syntax error beforeProjectPointOntoVector’
cons: *** [release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.o] Error 1
cons: errors constructing release-x86-FreeBSD-2.2/cgame/src/cgame/cg_q_math.o

Anyone ideas?

FYI: It does compile correct under a Win32 env.


(RR2DO2) #13

For FreeBSD compiling you will likely have to modify some ifdefs, as the section that those errors are being generated by shouldn’t be compiling on *nix (though only linux precompiler directives are present). Also, why are you compiling from modified source? There shouldn’t be any need to move q_math.c to cg_q_math.c.


(Leff) #14

I tried to patch the vsay exploit, and the cg_q_math.c is just automatically generated when running the ‘cons’ script
However, I just gave up under BSD, and pulled up a Linux distro , and it compiled without problems.

Grtz, Leff.

Update:
“libstdc++.so.5: cannot open shared object file: No such file or directory”

Damn :confused:
Is it just a case of altering these in the header file ?


//======================= LINUX DEFINES =================================

// the mac compiler can't handle >32k of locals, so we
// just waste space and make big arrays static...
#ifdef __linux__

#define	MAC_STATIC

#ifdef __i386__
#define	CPUSTRING	"linux-i386"
#elif defined __axp__
#define	CPUSTRING	"linux-alpha"
#else
#define	CPUSTRING	"linux-other"
#endif

#define	PATH_SEP '/'

#endif


(duke'ku) #15

how would one go about doing that? :moo:


(Rain) #16

The main reason the Linux-specific ifdefs exist is because of the different syntax MSVC and GCC use for inline assembly. You could try changing the linux defines to GNUC instead.


(nomad) #17

Following earlier posts I have not been able to compile on a Redhat 7.3 server.

I use the following:

./cons – release

and it complains saying it cant find gcc- but it is installed v 2.96 via RPMS.

Any ideas?

Enemy Territory version 2.56
cpu : x86
OS : Linux
libc: 2.2
configured for release build, in directory release-x86-Linux-2.2
CFLAGS: -pipe -fsigned-char -DMISSIONPACK -DNDEBUG -O6 -mcpu=pentiumpro -march=pentium -fomit-frame-pointer -ffast-math -fno-strict-aliasing -fstrength-reduce -malign-loops=2 -malign-jumps=2 -malign-functions=2
sh: gcc-2.95: command not found
which: no ccache in (/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/bin/X11:/usr/X11R6/bin:/usr/local/scripts:/usr/local/mysql/bin:/root/bin)
Ignoring missing script “/chroot/httpd/usr/local/games/code/head/src/extractfuncs/Conscript” (script::Build in Construct, line 334) at ./cons line 749.
cons: error in file “Conscript-game” (cons: variable “CC” exported but not defined by file “Construct”)
cons: error in file “Conscript-cgame” (cons: variable “CC” exported but not defined by file “Construct”)
cons: error in file “Conscript-ui” (cons: variable “CC” exported but not defined by file “Construct”)
cons: script errors encountered: construction aborted


(nomad) #18

OK- found my own solution to this problem:
in WET_Source/src/unix/Cons_gcc.pm
line 17 is :
if($version =~ ‘2.[0-9].[0-9]’)

change it to be:
if($version =~ ‘2.[0-9]*’)


(tjw) #19

<strike>
For those who don’t want to much about with wine in order to extract the et source, you should know that the .exe is just a self extracting ZIP archive, so you can just unzip it.
</strike>

Nevermind, that doesn’t work since it seems to loose the required directory structure.


(Rain) #20

You can compile binaries that work with older glibc versions by forcing gcc to use older headers (I use glibc 2.2 headers when I do Linux etpro builds.) The headers choose the correct symbol to use for certain functions, and the linker will then stamp on the appropriate version for that symbol, so if your headers only use the glibc 2.2-specific stuff, you’ll avoid the glibc 2.3 dependency.

Quick example:
glibc 2.3’s ctype functions (e.g. tolower(), toupper()) use some special helper functions that previous versions of glibc didn’t provide (which are called from the tolower() function defined in ctype.h), so when using the glibc 2.3 headers you end up requiring glibc 2.3:

  required from libc.so.6:
    0x0d696911 0x00 06 GLIBC_2.1
    0x09691f73 0x00 05 GLIBC_2.1.3
    0x0d696913 0x00 04 GLIBC_2.3
    0x0d696910 0x00 02 GLIBC_2.0

[...]
SYMBOL TABLE:
[...]
00000000       F *UND*  00000071              __ctype_tolower_loc@@GLIBC_2.3
00000000       F *UND*  00000071              __ctype_toupper_loc@@GLIBC_2.3
00000000       F *UND*  00000071              __ctype_b_loc@@GLIBC_2.3

If you use glibc 2.2’s headers to compile, the newer ctype functions aren’t used, the symbols for the helper functions aren’t referenced, and you get a build that’ll work on older systems:

  required from libc.so.6:
    0x0d696911 0x00 05 GLIBC_2.1
    0x09691f73 0x00 03 GLIBC_2.1.3
    0x0d696910 0x00 02 GLIBC_2.0

[...]
SYMBOL TABLE:
[...]
00000000       O *UND*  00000004              __ctype_tolower@@GLIBC_2.0
00000000       O *UND*  00000004              __ctype_toupper@@GLIBC_2.0

You can tell gcc to use a different set of system headers like so:

gcc -nostdinc -I/path/to/alternate/glibc/headers -I/path/to/gcc/headers

…and you can easily find the path of gcc’s own headers (for e.g. stdinc.h) with:

gcc --print-file-name=include

I do something like this in the etpro makefiles:

ifeq ($(BUILDHOST)-$(WIN32),portal-0)
        CFLAGS_COMMON += -nostdinc -I/usr/local/glibc-2.2-headers -I$(GCC_HEADERS)
ifeq ($(GCC3),1)
        CFLAGS_COMMON += -pedantic -std=c99
endif
endif

[...]

GCC_HEADERS=$(shell $(CC) --print-file-name=include)

There is one caveat to this: when generating dependencies, gcc -MM won’t work as expected (it’ll work like gcc -M), because it won’t treat the glibc 2.2 headers as “systemâ€? headers.