Bug 198537

Summary: games/openarena doesn't build with newer audio/speex
Product: Ports & Packages Reporter: emmh
Component: Individual Port(s)Assignee: Roman Bogorodskiy <novel>
Status: Closed FIXED    
Severity: Affects Some People CC: kami, kamikaze, marino, multimedia, novel
Priority: --- Keywords: needs-patch
Version: LatestFlags: koobs: maintainer-feedback? (kamikaze)
Hardware: Any   
OS: Any   
Attachments:
Description Flags
Output of make none

Description emmh 2015-03-12 09:49:53 UTC 
Created attachment 154238 [details]
Output of make

openarena doesn't build with speex-1.2.r2,1

[root@******* /usr/ports/games/openarena]#make
[...]
CC code/libspeex/bits.c
code/libspeex/bits.c:109:6: error: conflicting types for 'speex_bits_read_from'
void speex_bits_read_from(SpeexBits *bits, char *chars, int len)
     ^
/usr/local/include/speex/speex_bits.h:80:6: note: previous declaration is here
void speex_bits_read_from(SpeexBits *bits, const char *bytes, int len);
     ^
code/libspeex/bits.c:156:6: error: conflicting types for
      'speex_bits_read_whole_bytes'
void speex_bits_read_whole_bytes(SpeexBits *bits, char *chars, int nbytes)
     ^
/usr/local/include/speex/speex_bits.h:88:6: note: previous declaration is here
void speex_bits_read_whole_bytes(SpeexBits *bits, const char *bytes, int len);
     ^
2 errors generated.
[...]

# uname -a
FreeBSD ******* 10.1-RELEASE-p6 FreeBSD 10.1-RELEASE-p6 #0: Tue Feb 24 18:57:59 UTC 2015     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386

speex-1.2.r2,1
Comment 1 Dominic Fandrey freebsd_committer freebsd_triage 2015-03-26 13:22:01 UTC 
I investigated this issue.

To make sure the speex version is in sync with other clients I always build INTERNAL_SPEEX, i.e. the code that is shipped with OpenArena/ioquake3. However the build system seems to get the order of include folders wrong, so that the internal code gets tainted with system headers.

There are two approaches to solving this:
- Introduce a dependency to audio/speex and use the library
- Try to fix the build system (in all ioquake3 derivatives)

The first one is the lazy solution, the impact on inter-client compatibility is probably null, but I cannot guarantee that.

Any thoughts concerning that?
Comment 2 John Marino freebsd_committer freebsd_triage 2015-04-16 09:44:12 UTC 
FYI, I am seeing the same issue on flightgear when it's built with gcc5.
Comment 3 Dominic Fandrey freebsd_committer freebsd_triage 2015-04-16 09:52:32 UTC 
The build logic of INTERNAL_SPEEX seems to be broken. I'll go the easy way and add a dependency.
Comment 4 John Marino freebsd_committer freebsd_triage 2015-04-16 09:53:48 UTC 
it's not easier to patch the build logic?
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2015-04-17 09:54:06 UTC 
Kami, do you want to assign this to yourself?
Comment 6 Dominic Fandrey freebsd_committer freebsd_triage 2015-04-22 09:20:10 UTC 
(In reply to Kubilay Kocak from comment #5)

Thank you, done. I simply forgot about clicking that.

I have a fix, am working on porting that to all the ioq3 derived ports.
Comment 7 John Marino freebsd_committer freebsd_triage 2015-05-16 18:28:55 UTC 
Dominic,
Can openarena be separated from ioquake3?

Ioquake3 just does not build on GCC 4.8 or later and I want to remove it from dports.  I tried; but openarena and other ports immediately had issues.  I see now that openarena has ".include ../../ioquake/Makefile" in it.

Is this really necessary?  ports should be standalone unless they are directly related and pulling in a common helper file.  I'm not sure this is the case here.

I think there are other ports not just openarena affected by this interlinking too.  

If they truly need a common mk file, then maybe it should move to Mk or Mk/Uses.  Otherwise I think they should be separate.  I should not have to purge 3-4 games just to eliminate ioquake3.  Can anything be done here?
Comment 8 John Marino freebsd_committer freebsd_triage 2015-07-03 08:43:52 UTC 
(In reply to John Marino from comment #7)
I'd like to follow up on comment#7 (Dominic).  Should I open a new PR?
Comment 9 Roman Bogorodskiy freebsd_committer freebsd_triage 2015-09-30 15:33:07 UTC 
Should be fixed now: https://svnweb.freebsd.org/changeset/ports/398219