Resolves an issue where the macOS application's dylibs could not be
loaded because there were too many maps; on macOS the default maximum
number of open files is 256.
Sys_BinaryPathRelative takes a parameter which is path concatenated with
Sys_BinaryPath, and resolved to a canonical path. The intended use case
is to facilitate the situation where you want the game data directory to
exist outside the same directory in which the binary lives, but relative
to it. More specifically, if you want to distriute multiple binaries for
different architectures, in the same tree, this allows for a means of
having said binaries in architecture subdirectories, with a shared data
directory, e.g.:
ioq3/x86/ioquake3.exe etc.
ioq3/x86_64/ioquake3.exe etc.
ioq3/baseq3/pak0.pk3 etc.
Here, when building you would define DEFAULT_RELATIVE_BASEDIR=".." by
appending it to the build system CFLAGS, and then the executables will
by default look in their parent directory for the data.
The macOS client and server were completely unusable when run from a
terminal. They blocked forever in `[NSApp run];` which was called by
Sys_InitProtocolHandler(). `applicationDidFinishLaunching` was never
called to exit the NSApp run loop.
Use SDL's SDL_DROPFILE event to receive URLs to handle on macOS instead.
This also handles URLs while the game is running (connect to new server)
instead of nothing happening when clicking a link while the game is
running.