loki_patch nightmares continue...

Ryan C. Gordon icculus at clutteredmind.org
Wed Jan 1 13:26:21 EST 2003

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


("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.


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


More information about the Lokisetup mailing list