Two portability bugs in recent svn, caught by Debian experimental's buildbots:
1. The pluggable renderer takes the address of Q_ftol as a function pointer. This is OK on x86-64, where Q_ftol is an object-like macro (qftolsse), and on i386, where Q_ftol is itself a function pointer, pointing to either qftolx87 or qftolsse. However, it's not OK on non-x86 platforms, where Q_ftol(f) is currently a function-like macro expanding to lrintf(f). The easy fix is to change the definition of Q_ftol so it expands to lrintf as an object-like macro.
(It occurs to me that the CPU cost of performing a call through a function pointer could easily outweigh the performance benefit of using the optimal opcode for ftol - has anyone benchmarked this? Perhaps the pluggable renderer should just use lrintf, link to libm and trust that it's sufficiently well-implemented?)
2. q_platform.h doesn't declare CopyShortSwap or CopyLongSwap, breaking the build on platforms where CopyLittleShort and CopyLittleLong expand to those (i.e. anything big-endian).
With these patches, ioquake3 compiles on a powerpc (which is big-endian, so it'd suffer from both bugs). I haven't tried the resulting binaries yet.
Created attachment 2896[details]
[PATCH 1/2] q_platform: declare CopyShortSwap, CopyLongSwap
This fixes failure to build from source on big-endian platforms.
Created attachment 2897[details]
[PATCH 2/2] q_shared: define Q_ftol as something whose address can be taken
This fixes failure to build from source on all non-x86 platforms.
Created attachment 2896 [details] [PATCH 1/2] q_platform: declare CopyShortSwap, CopyLongSwap This fixes failure to build from source on big-endian platforms.Created attachment 2897 [details] [PATCH 2/2] q_shared: define Q_ftol as something whose address can be taken This fixes failure to build from source on all non-x86 platforms.