Wrong (older and incompatible) glibc? If that's the case your binary should have been loudly screaming about symbols (loudly, if launched from the command line where you can see output of course). Proprietary binary only software is usually compiled against old glibc (or even have the C functions statically linked) so that doesn't happen. For example my Unreal Tournament 2004 still runs to this day (needs libstdc++.so.5 though, but I just drop one in the program directory)
libssl versions can be a pain in the ass though.
When something like that happens, consider dropping compatible libraries in the program directory instead of installing (incompatible) versions to the system where they are going to interfere. If the program doesn't find them there, set a LD_LIBRARY_PATH environment variable before launching the program. That can be done in a script, or often at the command line.
Code:
LD_LIBRARY_PATH=/opt/pt:$LD_LIBRARY_PATH packettracer
or....
Code:
#! /bin/sh
export LD_LIBRARY_PATH=/opt/pt:$LD_LIBRARY_PATH
packettracer
or...
Code:
#! /bin/sh
cd /opt/pt
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
./packettracer
(setting it to . for the current working directory)
What the appending of $LD_LIBRARY_PATH is about is good practice when setting an environment variable so you append any existing value to the new one (though LD_LIBRARY_PATH will NOT be set by default. It's not how things are done, it's only used to override). But I do the same thing with PATH or any other directory based variable when I override system defaults. For example PATH=/opt/pt:$PATH so it doesn't REMOVE /bin and /usr/bin and friends lol
Bookmarks