loki_patch nightmares continue...

[Ryan C. Gordon]

There doesn't seem to be a magic bullet static binary that runs
universally:

  https://bugzilla.icculus.org/show_bug.cgi?id=330

("TLS" is "Thread Local Storage", btw.)

Is it a bad idea to change the update.sh to look for loki_patch in the
$PATH before running our own? This would allow us to:

1) Let individual distros ship their own patch binary that won't have
glibc issues.
2) Let us at least override the included loki_patch when things like this
happen. As it currently stands, I have to have this guy unpack the patch
archive with --keep, dig around to replace a binary, run it manually, and
then clean up the archive afterwards...and then do it again for the next
patch. It'd be easier to say "here, drop this new binary into your $PATH
and execute the downloaded .run file again."

The cons:

1) An older loki_patch sitting in the $PATH might lack functionality
required for a newer patch. The hope is that loki_patch is a small binary
that does a single unit of work in grand Unix style, and won't ever need
more functionality included (yeah, right), and is 100% bug free (yeah,
right). The solution is that a) if it came from a distro, the distro will
have upgraded packages and b) we can still override it by putting
something else in the $PATH. It would just need to be abundantly clear
what version of loki_patch is being used so the problem could be
pinpointed quickly.

Thoughts?

Also, this might be a dumb question, but is there a reason we statically
link loki_patch? I've got millions of lines of complex game code that has
to be compatible with a million glibc, SDL, OpenAL, X11, ALSA, esd,
OpenGL, etc libraries, and has no problems, but I can't get a simple stdio
program that shuffles bits around to function because of this? Perhaps the
static linking is causing problems with the exact thing it was meant to
avoid?

--ryan.