Page 1 of 5 1 2 3 ... LastLast
Results 1 to 20 of 98

  Click here to go to the first staff post in this thread.   Thread: Compiling a mod under GNU/Linux

  1. #1

    Compiling a mod under GNU/Linux

    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.

  2. #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

  3. #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).

  4. #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

  5. #5
    I tried that, but it gives me a "bad interpreter" error.

  6. #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.?

  7. #7
    Yes, I copied and pasted it. And the standard line doesn't work either
    I am using Gentoo.

  8. #8
    Uh Gentoo brr... 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?

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

  10. #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

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

  12. #12

    Error :(

    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 parameter `sr'
    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 parameter `sy'
    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 parameter `cp'
    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 before `angle'
    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 before `for'
    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 of `j'
    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 before `ProjectPointOntoVector'
    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.

  13.   This is the last staff post in this thread.   #13
    Chief Technology Officer RR2DO2's Avatar
    Join Date
    Dec 2001
    Location
    London, UK
    Posts
    302
    Most Recent Awards:

    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.

  14. #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 :/
    Is it just a case of altering these in the header file ?
    Code:
    //======================= 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

  15. #15
    Quote Originally Posted by RR2DO2
    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.
    how would one go about doing that? :moo:

  16. #16
    Senior Member Rain's Avatar
    Join Date
    Sep 2003
    Location
    Pining for the fjords
    Posts
    480
    Most Recent Awards:

    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.

  17. #17

    Compiling on Redhat 7.3 system- no joy

    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

  18. #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]*')

  19. #19

    use wet_source.exe without wine

    <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.

  20. #20
    Senior Member Rain's Avatar
    Join Date
    Sep 2003
    Location
    Pining for the fjords
    Posts
    480
    Most Recent Awards:

    How to support older versions of glibc on a glibc 2.3 system

    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:
    Code:
      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:
    Code:
      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:
    Code:
    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:
    Code:
    gcc --print-file-name=include
    I do something like this in the etpro makefiles:
    Code:
    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.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •