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
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?
FYI, I am seeing the same issue on flightgear when it's built with gcc5.
The build logic of INTERNAL_SPEEX seems to be broken. I'll go the easy way and add a dependency.
it's not easier to patch the build logic?
Kami, do you want to assign this to yourself?
(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.
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?
(In reply to John Marino from comment #7) I'd like to follow up on comment#7 (Dominic). Should I open a new PR?
Should be fixed now: https://svnweb.freebsd.org/changeset/ports/398219