Pages: [1]
  Print  
Author Topic: OpenArena/engine.git on github  (Read 33503 times)
hairball
Half-Nub


Cakes 2
Posts: 52


« on: February 06, 2014, 10:48:41 PM »

There's an updated client/server on github to match OpenArena 0.8.8 changes.  It's a fork of the official ioquake3 repository.  It should be fully integrated with the latest ioquake3 changes.

Please help test!  It builds and runs fine on Debian unstable.  It probably won't build nicely on Windows since ioquake3 is missing vorbis..  It should build on Windows with the experimental/latest-libraries branch.  Any changes related to making the build cross-platform should be sent to the ioquake3 project.

See README_OpenArena.md for details.

Update: ioquake3 doesn't include vorbis so the Windows compile will fail in master.  Try the experimental/latest-libraries branch which includes vorbis 1.3.4 and libcurl 7.35.0.  It cross compiles on Debian with that branch.

Update: If you want to help test, there's an experimental/latest-libraries-sdl2 branch that merges vorbis, curl and ioquake3's sdl2 branch.  SDL 1.2 is (almost) dead and they want all games to move to SDL 2.x.  SDL 2.x officially supports WinXP/Vista/7/8, Linux 2.6+, OS X 10.5+, iOS 5.1.1+ and Android 2.3.3+ with unofficial support for (Free|Open|Net)BSD and Solaris.

Update: ioquake3 upstream is moving to SDL2 at some point.  Their sdl2 branch is considered done but they haven't merged it into the master branch yet.  They are not leaving SDL 1.2 in the tree so there won't be a #ifdef to enable SDL 1.2.

Update: Travis CI is enabled for commits and pull requests.
« Last Edit: February 10, 2014, 03:56:50 PM by hairball » Logged
stigmha
Nub


Cakes 0
Posts: 24


Bit by bit


WWW
« Reply #1 on: February 07, 2014, 07:02:04 AM »

Awesome, gj!  Cheesy

Windows 7 - MinGW - GCC 4.8.1

First attempt

My first build attempt was without any modifications to Makefile.OpenArena, even though I knew it would fail with USE_CODEC_VORBIS=1. Result as expected:

Code:
code/client/snd_codec_ogg.c:35:31: fatal error: vorbis/vorbisfile.h: No such fil
e or directory
 #include <vorbis/vorbisfile.h>
                               ^
compilation terminated.
make[2]: *** [build/release-mingw32-x86/client/snd_codec_ogg.o] Error 1

Second attempt

  • USE_CODEC_VORBIS=0
  • USE_CODEC_OPUS=0

Code:
code/libs/win32/libcurl.a(strequal.o):strequal.c:(.text+0x14): undefined referen
ce to `strcasecmp'
code/libs/win32/libcurl.a(strequal.o):strequal.c:(.text+0x48): undefined referen
ce to `strncasecmp'
collect2.exe: error: ld returned 1 exit status

The good old libcurl error again. Can be fixed by downgrading GCC to 4.6.3, or by upgrading cURL. I will report this to the devs of ioquake3 once I get an account at their reporting tool. It will probably also be followed up by the ui macro issue which I will also report. Both issues with solutions are found here.

Mac OSX Mavericks (10.9.1) - Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)

First attempt

My first build attempt was without any modifications to Makefile.OpenArena. Result:

Code:
ld: warning: ingoring file /usr/local/lib/libvorbisfile.a, file was built for archive which is not in the architecture being linked (i386): /usr/local/lib/libvorbisfile.a
ld: warning: ingoring file /usr/local/lib/libvorbisfile.a, file was built for archive which is not in the architecture being linked (i386): /usr/local/lib/libvorbisfile.a
Undefined symbols for arccitecture i386
  "_ov_clear", referenced from:
      _S_OGG_CodecOpenStream in snd_codec_ogg.o
      _S_OGG_CodecCloseStream in snd_codec_ogg.o
  "_ov_info", referenced from:
      _S_OGG_CodecOpenStream in snd_codec_ogg.o
  "_ov_open_callbacks", referenced from:
      _S_OGG_CodecOpenStream in snd_codec_ogg.o
  "_ov_pcm_total", referenced from:
      _S_OGG_CodecOpenStream in snd_codec_ogg.o
  "_ov_read", referenced from:
      _S_OGG_CodecReadStream in snd_codec_ogg.o
  "_ov_seekable", referenced from:
      _S_OGG_CodecOpenStream in snd_codec_ogg.o
  "_ov_streams", referenced from:
      _S_OGG_CodecOpenStream in snd_codec_ogg.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Attempting to build ioquake3 without your modifications and with USE_CODEC_VORBIS gives the same result. Compiler architecture is not being set properly for OSX, I will report this to the ioquake3 devs as well.

Second attempt

  • USE_CODEC_VORBIS=0
  • USE_CODEC_OPUS=0

SUCCESS!

Third extra attempt

  • USE_CODEC_VORBIS=0
  • USE_CODEC_OPUS=1

SUCCESS!

Ubuntu 13.10 - GCC 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)

First attempt

My first build attempt was without any modifications to Makefile.OpenArena. Result:

SUCCESS!

EXTRA: General error (all systems)

  • USE_RENDERER_DLOPEN=0

Result:
Code:
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_animation.o: No such fil
e or directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_backend.o: No such file
or directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_bsp.o: No such file or d
irectory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_cmds.o: No such file or
directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_curve.o: No such file or
 directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_flares.o: No such file o
r directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_font.o: No such file or
directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_image.o: No such file or
 directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_image_png.o: No such fil
e or directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_image_jpg.o: No such fil
e or directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_image_bmp.o: No such fil
e or directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_image_tga.o: No such fil
e or directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_image_pcx.o: No such fil
e or directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_init.o: No such file or
directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_light.o: No such file or
 directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_main.o: No such file or
directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_marks.o: No such file or
 directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_mesh.o: No such file or
directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_model.o: No such file or
 directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_model_iqm.o: No such fil
e or directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_noise.o: No such file or
 directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_scene.o: No such file or
 directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_shade.o: No such file or
 directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_shade_calc.o: No such fi
le or directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_shader.o: No such file o
r directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_shadows.o: No such file
or directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_sky.o: No such file or d
irectory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_surface.o: No such file
or directory
cc.exe: error: build/release-mingw32-x86/renderergl1/tr_world.o: No such file or
 directory
make[2]: *** [build/release-mingw32-x86/openarena.x86.exe] Error 1

This is a general error related to your modifications in the Makefile I think. I might look into it if I have time a bit later today, but not right now.

EXTRA: Windows Visual Studio

Old, not working, and outdated... as with ioquake3. I can, if you are interested, provide a working Visual Studio 2013 project for the repo. It will be different from ioquake3 anyways, as it requires the OA renderer, different icons, and names.
Logged
hairball
Half-Nub


Cakes 2
Posts: 52


« Reply #2 on: February 07, 2014, 04:22:14 PM »

Thanks for the feedback.  I'm mostly limited to testing in Linux.

Quote
My first build attempt was without any modifications to Makefile.OpenArena

You should never need to modify Makefile.OpenArena unless you think we should change the default for everyone.  Use Makefile.local when you want to override parts of Makefile.OpenArena.  Makefile.local is in .gitignore so it will never get committed and you can keep your local flags while staying in sync with the latest changes.

Quote
USE_RENDERER_DLOPEN=0

Sigh ... the USE_RENDERER_DLOPEN=0 was a last minute mistake on my part.  I had been testing that all along but then I forgot to test it after I changed the default $(CLIENTBIN) to use openarena1 instead of opengl1.  Fixed in git.

Quote
EXTRA: Windows Visual Studio

Old, not working, and outdated... as with ioquake3. I can, if you are interested, provide a working Visual Studio 2013 project for the repo. It will be different from ioquake3 anyways, as it requires the OA renderer, different icons, and names.
I think if we get enough requests or a patch from someone it would be fine.  On the other hand, if the mingw on Win7 or cross-compile on Linux work out for Windows users, I think there's less of a need for this.
Logged
hairball
Half-Nub


Cakes 2
Posts: 52


« Reply #3 on: February 08, 2014, 11:58:36 AM »

Windows 7 - MinGW - GCC 4.8.1
... even though I knew it would fail with USE_CODEC_VORBIS=1.
... The good old libcurl error again. Can be fixed by downgrading GCC to 4.6.3, or by upgrading cURL.
Downgrade gcc?  Yuck Smiley

Could you try the experimental/latest-libraries branch?  I upgraded cURL to 7.35.0 and included vorbis 1.3.4.  It cross compiles now.

By the way, I have a repository for stuff that's meant for upstream ioquake3.  https://github.com/xhairball/ioq3
« Last Edit: February 08, 2014, 12:04:50 PM by hairball » Logged
stigmha
Nub


Cakes 0
Posts: 24


Bit by bit


WWW
« Reply #4 on: February 08, 2014, 02:28:12 PM »

You should never need to modify Makefile.OpenArena unless you think we should change the default for everyone.

I am aware, was just lazy for testing purposes, but thanks anyway.  Wink

I think if we get enough requests or a patch from someone it would be fine.  On the other hand, if the mingw on Win7 or cross-compile on Linux work out for Windows users, I think there's less of a need for this.

I will primarily promote it for ioquake3 first, I am just a bit busy during weekends, so I haven't done it yet. Visual studio has an awesome visual debugger and profiler, which is why I am such a fan. I can also provide an updated XCode project a bit later. Other than that, there is already a broken MSVC project there, so why just not replace it with a working one? I think the broken one has created enough confusion already... at least from what I have seen on the forums.

Over to the testing...

Windows 7/8 features/upgrade-curl-7.35.0

Worked as far as I know, but fails in Windows due to the ui macro issue that I got a solution to here: http://community.ioquake.org/t/building-ioquake3-using-mingw-on-windows-7-fails/198/3. This means that it passed the cURL compilation, as the macro error only appears after the cURL build! The macro error is also in ioquake3, which I think I'll report tomorrow as I am short on time now.

Windows 7/8 features/add-vorbis-1.3.4

Created Makefile.local, added USE_CODEC_VORBIS=1, ran make. It compiled until the good old cURL error occured, which means that the compilation of vorbis went fine. I then merged it with features/upgrade-curl-7.35.0 and I got the same macro error as with features/upgrade-curl-7.35.0.

That's unfortunately all I have time for right now :-)

BTW: anyone else but me that have noticed the forums becoming really slow lately? ... it messed up this post badly (fixed now).
« Last Edit: February 08, 2014, 02:33:22 PM by stigmha » Logged
hairball
Half-Nub


Cakes 2
Posts: 52


« Reply #5 on: February 08, 2014, 03:26:07 PM »

I will primarily promote it for ioquake3 first, I am just a bit busy during weekends, so I haven't done it yet. Visual studio has an awesome visual debugger and profiler, which is why I am such a fan. I can also provide an updated XCode project a bit later. Other than that, there is already a broken MSVC project there, so why just not replace it with a working one? I think the broken one has created enough confusion already... at least from what I have seen on the forums.
Sounds fine to me.  I try to push as much up to ioquake3 as possible.

Worked as far as I know, but fails in Windows due to the ui macro issue that I got a solution to here: http://community.ioquake.org/t/building-ioquake3-using-mingw-on-windows-7-fails/198/3. This means that it passed the cURL compilation, as the macro error only appears after the cURL build! The macro error is also in ioquake3, which I think I'll report tomorrow as I am short on time now.
I think the macro error is unrelated to the cURL build.  I agree that it's probably something in your system headers.  I don't think it's a typedef to unsigned int though because that's not what the gcc message indicates.  I think somewhere it has something equivalent to #define ui <constant> in a system header.

Here's an example of a local file.  It would be obvious if it's in the code directly in either gcc or clang:
Code:
$ cat example.c
#define ui 20

typedef union {
    float f;
    int i;
    unsigned int ui;
} floatint_t;

$ gcc -Wall -Wextra -c example.c
example.c:1:12: error: expected identifier or ‘(’ before numeric constant
 #define ui 20
            ^
example.c:6:18: note: in expansion of macro ‘ui’
     unsigned int ui;
                  ^
example.c:7:1: warning: no semicolon at end of struct or union [enabled by default]
 } floatint_t;
 ^
$ clang -Weverything -c example.c
example.c:6:18: error: expected member name or ';' after declaration specifiers
    unsigned int ui;
    ~~~~~~~~~~~~ ^
example.c:1:12: note: expanded from macro 'ui'
#define ui 20
           ^
example.c:6:17: error: expected ';' at end of declaration list
    unsigned int ui;
                ^
                ;
2 errors generated.

If it's a local header, both compilers find it:

Code:
$ cat /usr/include/ui_constant.h
#ifndef UI_CONSTANT_H
#define UI_CONSTANT_H

#define ui 20

#endif

$ cat example_local.c                           
#include "ui_constant.h"

typedef union {
    float f;
    int i;
    unsigned int ui;
} floatint_t;

$ gcc -Wall -Wextra -c example_local.c                             
In file included from example_local.c:1:0:
ui_constant.h:4:12: error: expected identifier or ‘(’ before numeric constant
 #define ui 20
            ^
example_local.c:6:18: note: in expansion of macro ‘ui’
     unsigned int ui;
                  ^
example_local.c:7:1: warning: no semicolon at end of struct or union [enabled by default]
 } floatint_t;
 ^
$ clang -c example_local.c                             
example_local.c:6:18: error: expected member name or ';' after declaration specifiers
    unsigned int ui;
    ~~~~~~~~~~~~ ^
./ui_constant.h:4:12: note: expanded from macro 'ui'
#define ui 20
           ^
example_local.c:6:17: error: expected ';' at end of declaration list
    unsigned int ui;
                ^
                ;
2 errors generated.

However, if it's in a system header, gcc won't complain because it assumes system headers are fine.  Gcc doesn't help with -Wsystem-headers.  clang finds it by default and with everything enabled.

Code:
# Dummy ... delete when done
$ cat /usr/include/ui_constant.h
#ifndef UI_CONSTANT_H
#define UI_CONSTANT_H

#define ui 20

#endif

$ cat example_sys.c
#include <ui_constant.h>

typedef union {
    float f;
    int i;
    unsigned int ui;
} floatint_t;

$ gcc -Wall -Wextra -c example_sys.c
In file included from example_sys.c:1:0:
example_sys.c:8:18: error: expected identifier or ‘(’ before numeric constant
     unsigned int ui;
                  ^
example_sys.c:9:1: warning: no semicolon at end of struct or union [enabled by default]
 } floatint_t;
 ^

$ gcc -Wall -Wextra -Wsystem-headers -c example_sys.c
In file included from example_sys.c:1:0:
example_sys.c:8:18: error: expected identifier or ‘(’ before numeric constant
     unsigned int ui;
                  ^
example_sys.c:9:1: warning: no semicolon at end of struct or union [enabled by default]
 } floatint_t;
 ^

$ clang -c example_sys.c
example_sys.c:8:18: error: expected member name or ';' after declaration specifiers
    unsigned int ui;
    ~~~~~~~~~~~~ ^
/usr/include/ui_constant.h:4:12: note: expanded from macro 'ui'
#define ui 20
           ^
example_sys.c:8:17: error: expected ';' at end of declaration list
    unsigned int ui;
                ^
                ;
2 errors generated.

$ clang -Weverything -c example_sys.c
example_sys.c:8:18: error: expected member name or ';' after declaration specifiers
    unsigned int ui;
    ~~~~~~~~~~~~ ^
/usr/include/ui_constant.h:4:12: note: expanded from macro 'ui'
#define ui 20
           ^
example_sys.c:8:17: error: expected ';' at end of declaration list
    unsigned int ui;
                ^
                ;
2 errors generated.

Above is the same symptom that you are seeing.  If you run it through clang, it would probably tell you what's wrong.  gcc is making strides in their warnings and errors but they haven't matched clang yet.

Code:
$ gcc --version
gcc (Debian 4.8.2-14) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ clang --version
Debian clang version 3.4-1 (tags/RELEASE_34/final) (based on LLVM 3.4)
Target: x86_64-pc-linux-gnu
Thread model: posix
« Last Edit: February 08, 2014, 03:47:10 PM by hairball » Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #6 on: February 09, 2014, 11:14:20 AM »

I am just starting to look at it. So far the native compile on Linux went fine. The cross compile did fail because vorbis is missing.
Code:
sudo aptitude install mingw-w64
PLATFORM=mingw32 ARCH=x86 make
ends with:
Code:
code/client/snd_codec_ogg.c:35:31: fatal error: vorbis/vorbisfile.h: Ingen sådan fil eller filkatalog
compilation terminated.
make[2]: *** [build/release-mingw32-x86/client/snd_codec_ogg.o] Fejl 1
I apologize for the danish messages but they say "No such file ore directory" and "Error 1".

ioquake includes binary versions of SDL and curl to easy the compilation of windows-binaries but not vorbis. I have included them previously but I think that it should be included at a higher level. I know people warn against including them but hunting required libraries on Windows is just much more annoying than under Linux.
Logged

There are nothing offending in my posts.
hairball
Half-Nub


Cakes 2
Posts: 52


« Reply #7 on: February 09, 2014, 12:27:34 PM »

I am just starting to look at it. So far the native compile on Linux went fine. The cross compile did fail because vorbis is missing.
Yeah, that's a known issue.  Can you try the experimental/latest-libraries branch?  I included vorbis and the latest curl there.  I already submitted a pull request to ioquake3 for including vorbis (waiting on approval).  Once I get some Windows user feedback on curl 7.35.0, I'll send ioquake3 a pull request for that too.

ioquake includes binary versions of SDL and curl to easy the compilation of windows-binaries but not vorbis. I have included them previously but I think that it should be included at a higher level. I know people warn against including them but hunting required libraries on Windows is just much more annoying than under Linux.
Yes, I agree it should be at the ioquake3 level.  That's why I'm holding off on moving it into OA until I hear whether ioquake3 will accept it.  They have USE_CODEC_VORBIS and their README says optional ogg vorbis support.  However, they don't include vorbis so it doesn't work.

In the past OA release, it included vorbis as a DLL.  I think it's more aligned with ioquake3 as a stripped down source directory.  I think they try to include things that will compile without autotools (or any kind of configure script outside of their single Makefile) as source and things that won't as binaries.  That's why libcurl and SDL are binaries but speex, ogg, opus, etc are all source compiles.  In the pull request, I included a source compile for vorbis since it doesn't require autotools.

By the way, I test this on Debian testing x86_64 and I cross compile to Windows x86 and x86_64 with mingw64.
Logged
stigmha
Nub


Cakes 0
Posts: 24


Bit by bit


WWW
« Reply #8 on: February 10, 2014, 05:54:01 AM »

Windows 7/8 - Clang v.3.4 (198054)

make CC=clang:

Code:
DED_CC code/server/sv_bot.c
clang.exe: error: unknown argument: '-falign-loops=2'
clang.exe: error: unknown argument: '-falign-jumps=2'
make[2]: *** [build/release-mingw32-x86/ded/sv_bot.o] Error 1

I just removed the flags temporarily from the Makefile under the MinGW section.The next attempt went all fine until:

Code:
LD build/release-mingw32-x86/openarena.x86.exe
clang.exe: error: unknown argument: '-mwindows'
make[2]: *** [build/release-mingw32-x86/openarena.x86.exe] Error 1

I also temporarily removed that flag, and tried yet again. Clang doesn't like Opus:

Code:
LD build/release-mingw32-x86/ioquake3.x86.exe
Cannot export _opus_decode: symbol not found
Cannot export _opus_decode_float: symbol not found
Cannot export _opus_decoder_create: symbol not found
Cannot export _opus_decoder_ctl: symbol not found
Cannot export _opus_decoder_destroy: symbol not found
Cannot export _opus_decoder_get_nb_samples: symbol not found
Cannot export _opus_decoder_get_size: symbol not found
Cannot export _opus_decoder_init: symbol not found
Cannot export _opus_encode: symbol not found
Cannot export _opus_encode_float: symbol not found
Cannot export _opus_encoder_create: symbol not found
Cannot export _opus_encoder_ctl: symbol not found
Cannot export _opus_encoder_destroy: symbol not found
Cannot export _opus_encoder_get_size: symbol not found
Cannot export _opus_encoder_init: symbol not found
Cannot export _opus_get_version_string: symbol not found
Cannot export _opus_multistream_decode: symbol not found
Cannot export _opus_multistream_decode_float: symbol not found
Cannot export _opus_multistream_decoder_create: symbol not found
Cannot export _opus_multistream_decoder_ctl: symbol not found
Cannot export _opus_multistream_decoder_destroy: symbol not found
Cannot export _opus_multistream_decoder_get_size: symbol not found
Cannot export _opus_multistream_decoder_init: symbol not found
Cannot export _opus_multistream_encode: symbol not found
Cannot export _opus_multistream_encode_float: symbol not found
Cannot export _opus_multistream_encoder_create: symbol not found
Cannot export _opus_multistream_encoder_ctl: symbol not found
Cannot export _opus_multistream_encoder_destroy: symbol not found
Cannot export _opus_multistream_encoder_get_size: symbol not found
Cannot export _opus_multistream_encoder_init: symbol not found
Cannot export _opus_multistream_packet_pad: symbol not found
Cannot export _opus_multistream_packet_unpad: symbol not found
Cannot export _opus_multistream_surround_encoder_create: symbol not found
Cannot export _opus_multistream_surround_encoder_get_size: symbol not found
Cannot export _opus_multistream_surround_encoder_init: symbol not found
Cannot export _opus_packet_get_bandwidth: symbol not found
Cannot export _opus_packet_get_nb_channels: symbol not found
Cannot export _opus_packet_get_nb_frames: symbol not found
Cannot export _opus_packet_get_nb_samples: symbol not found
Cannot export _opus_packet_get_samples_per_frame: symbol not found
Cannot export _opus_packet_pad: symbol not found
Cannot export _opus_packet_parse: symbol not found
Cannot export _opus_packet_unpad: symbol not found
Cannot export _opus_pcm_soft_clip: symbol not found
Cannot export _opus_repacketizer_cat: symbol not found
Cannot export _opus_repacketizer_create: symbol not found
Cannot export _opus_repacketizer_destroy: symbol not found
Cannot export _opus_repacketizer_get_nb_frames: symbol not found
Cannot export _opus_repacketizer_get_size: symbol not found
Cannot export _opus_repacketizer_init: symbol not found
Cannot export _opus_repacketizer_out: symbol not found
Cannot export _opus_repacketizer_out_range: symbol not found
Cannot export _opus_strerror: symbol not found
collect2.exe: error: ld returned 1 exit status
clang.exe: error: linker (via gcc) command failed with exit code 1 (use -v to se
e invocation)

Makefile.local -> USE_CODEC_OPUS=0, result: Success!

-------------

Conclusion: the ui macro is not defined for Clang, but it is for GCC 4.8.1 on MinGW and throws an error. It is not defined in MSVC and not in GCC on Ubuntu. I have not been able to locate the definition of the ui macro. I have attempted searching for it using grep and listing all GCC predefinitions (gcc -dM -E - < /dev/null). I did also attempt to create your test file with all the same system includes that q_shared.h use and to compile it with GCC:

Code:
// example_sys.c
#include <assert.h>
#include <math.h>
#include <stdio.h>
#include <stdarg.h>
#include <string.h>
#include <stdlib.h>
#include <time.h>
#include <ctype.h>
#include <limits.h>
#include <io.h>
#include <stdint.h>

typedef union {
    float f;
    int i;
    unsigned int ui;
} floatint_t;
// gcc -c example_sys.c

It compiles without any errors so I am a bit confused. I did some tests using #pragma message if ui is defined, and adding one at the top of q_shared.h (before all includes) results positive. So the macro must come from the Makefile somehow?

Update: yes, this is ioquake3 specific, so perhaps it should be discussed on their forums instead.

----------

Update 2 (10.02.2014 17:44 CET)

I have now submitted all the issues to ioquake3, and they probably hate me now  Tongue:

« Last Edit: February 10, 2014, 10:51:16 AM by stigmha » Logged
hairball
Half-Nub


Cakes 2
Posts: 52


« Reply #9 on: February 10, 2014, 03:55:51 PM »

Conclusion: the ui macro is not defined for Clang, but it is for GCC 4.8.1 on MinGW and throws an error. It is not defined in MSVC and not in GCC on Ubuntu. I have not been able to locate the definition of the ui macro. I have attempted searching for it using grep and listing all GCC predefinitions (gcc -dM -E - < /dev/null). I did also attempt to create your test file with all the same system includes that q_shared.h use and to compile it with GCC:
It doesn't look like a system header then if clang doesn't complain.  I highly doubt gcc would define ui.  They would use an underscore prefix which is reserved for compilers.

The makefile does define -DUI but not -Dui.  It shouldn't trip you up but I wonder if somehow it is getting switched or compared as lower case.  Again, this shouldn't happen.

Rather than using -dM -E, try this:

Code:
rm -rf build  # or deltree or whatever you use in Windows
make CFLAGS="-E -dD -dI" V=1 > make.log

That tells gcc to stop after preprocessing and to include all definitions with markers for include files.  It still writes to *.o files but they are not object files.  Open build/release-<whatever>-x86_64/**/ui_main.o.  Then search for all instances of UI or ui.  You should see the problem somewhere in there.  If not, let ioquake3 worry about it since it happens upstream. Smiley

I have now submitted all the issues to ioquake3, and they probably hate me now  Tongue
I doubt anyone would turn down legitimate bug reports.  It's not like you opened 6 reports on spelling mistakes. Smiley

I have a patch for CC=clang in xhairball/ioq3 but it doesn't include -mwindows since I tested it in Linux.  I can build opus with clang on Linux.
« Last Edit: February 10, 2014, 04:25:08 PM by hairball » Logged
stigmha
Nub


Cakes 0
Posts: 24


Bit by bit


WWW
« Reply #10 on: February 11, 2014, 12:22:07 PM »

ui macro issue

I got a fast reply on ioquake3's BugZilla, and it turned out to be a bug in MinGW. Any compiler defined macro (gcc -D<macro>) becomes case insensitive if there is a file or subdirectory in the root build directory with the same name as the macro. James Canete from ioquake3 found the reason and published a PoC: http://bugzilla-attachments.icculus.org/attachment.cgi?id=3409.

I filed a bug report at MinGW's Sourceforge and I assume further developments regarding the issue will be found there: http://sourceforge.net/p/mingw/bugs/2183/. The issue is non-existing in MinGW64 according to James Canete. I will not spend more time on this, but I will keep my temporary local fix until they release MinGW with GCC 4.8.2.

Clang fixes

I have a patch for CC=clang in xhairball/ioq3 but it doesn't include -mwindows since I tested it in Linux.  I can build opus with clang on Linux.

Look at l. 594 in your patched Makefile; CLIENT_LDFLAGS += -mwindows. Just wrap that in the same ifneq you used the other places and you are good to go! Smiley
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #11 on: March 16, 2014, 11:24:06 PM »

Good news everyone. I finally got git setup and working on my PC so now i'm starting to push over several changes one at a time.  So far as of this post it's Horz+ widescreen and fixed grayscale. More coming soon!


By the way, renderer_opengl2 can work if you delete the GLSL directory from patch088.pk3 - though I don't like how the renderer shades models, it screws up majorly around split edges.
« Last Edit: March 17, 2014, 01:57:23 PM by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
grey matter
Member


Cakes 8
Posts: 381

>9k


« Reply #12 on: March 21, 2014, 06:28:17 PM »

i'm starting to push over several changes one at a time.  So far as of this post it's fixed grayscale.
Any chance of you submitting your patches upstream to ioquake3?
Logged

This space is for rent.
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #13 on: March 24, 2014, 04:12:31 PM »

No.


Some of my changes are vendor specific and don't suit their 'be some generic sdl port with added features' vision, not to mention the personal harassment issues  coming from a certain Tim - which also costed one of the few Blender exporter coders OA relied on...


I am working to keep renderer_oa changes as self-contained as possible however.  Some of my old changes for sdl_glimp.c got moved to tr_extensions.c, etc.
« Last Edit: March 24, 2014, 04:20:33 PM by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
wing0
Half-Nub


Cakes 0
Posts: 72



WWW
« Reply #14 on: April 08, 2014, 04:40:17 PM »

This is relevant to my interest and I cloned.

Great job so far!
Logged

L!ve* is life - na na nana na
Hitchhiker
Member


Cakes 11
Posts: 181


« Reply #15 on: April 09, 2014, 12:31:53 PM »

I'm trying to (have tried) to upload my changes to the renderer. possibly someone can help?
I was not aware of the public/private keys until I went on to push the changes (when I cloned the engine I had no keys on my pc). Do you think this is causing me problem when uploading? I can correctly authenticate to github now but the push is rejected with a message access denied. Any help appreciated.
Thanks!
Logged
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3775


Trickster God.


« Reply #16 on: September 22, 2017, 06:58:03 AM »

Necrobumping because I'm having the Vorbis problem with current openarena-engine while cross-compiling from Linux Mint to Windows using mingw64. Any possible solutions to this?
Logged


"Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVT
Want to contribute? Read this.
Pages: [1]
  Print  
 
Jump to: