Execute code in kernel mode.

Applications Programming
21 
$ echo $LD_PRELOAD
speedhack.so
$ ls /usr/lib/*hack.so
/usr/lib/openglhack.so  /usr/lib/speedhack.so
22

Try export LD_PRELOAD="/usr/lib/speedhack.so"

Giving it the absolute path means you might even be able to keep it in /usr/local/lib/, not cluttered in with your actual system libraries.

---------- Post updated at 03:01 PM ---------- Previous update was at 02:48 PM ----------

Another thing just occurred to me. This is a 64-bit OS, right? Are some of these programs 32-bit? You'll need to compile a 32-bit speedhack.so for them (CFLAGS=-m32 in makefile) since you can't mix and match 32 and 64 bit libraries. Linux's message when this kind of conflict happens, "file not found", is singularly uninformative and took me a long time to get my head around.

23

I did:

$ ls /usr/lib/*hack*so
/usr/lib/openglhack32.so  /usr/lib/openglhack.so  /usr/lib/speedhack.so
$ export LD_PRELOAD=/usr/lib/openglhack32.so
$ quake4
ERROR: ld.so: object '/usr/lib/openglhack32.so' from LD_PRELOAD cannot be preloaded: ignored.0
...
24

I think you tried to preload the wrong library there... Anyway:

25

I see, but I don't know any way to give you more details. I always try to give as much details as I can.

openglhack32 is compiled (and linked) with -m32 and march-i386 (or something similar). So I don't know what to do now to test it for you.

26

For starters you could answer the question I did ask; are these programs in fact 32-bit? Is it only the 32-bit ones that are failing?

I'll add onto that, you can ldd /path/to/program and ldd /path/to/libspeedhack.so to see what things they demand and are loading.

It could still because you're hellbent on using C++, too. It could be pining for C++ libraries that the executable in question didn't bother to load, or conflicting with different versions it does load.

27

Quake4 seems to be 32 bits. The other one (tileracer) too.

Okay, this seems to be the problem. By the way, I compiled openglhack32 (which is a void override of glBegin) and speedhack32 (32 bit version of speedhack) and I did:

$ export LD_PRELOAD=speedhack32.so
$ quake4
ERROR: ld.so: object 'speedhack32.so' from LD_PRELOAD cannot be preloaded: ignored.
...
$ ldd /usr/lib32/speedhack32.so
    linux-gate.so.1 =>  (0xf7742000)
    libdl.so.2 => /lib32/libdl.so.2 (0xf770d000)
    libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7622000)
    libm.so.6 => /lib32/libm.so.6 (0xf75fb000)
    libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf75df000)
    libc.so.6 => /lib32/libc.so.6 (0xf7484000)
    /lib/ld-linux.so.2 (0xf7743000)

By the way, I don't know why it say it couldn't load but it seems to load, because I had speedhack (but openglhack didn't work).

I will post a conclusion when I understand a bit more of this situation. Thank you corona for help me. The ldd command helped me to secure that I'm loading 32 bits libraries.

28

I'd still like to see ldd quake4 . And I'd still like to know whether the programs that're failing are mostly 32-bit programs. And I'd still like to know if you're compiling all these as C++ and I'd still like to know what bits you really need to be C++.

It may be failing to preload parts of it but not all of it.

29

I'm compiling c++ with extern "C" (without it doesn't work). I'm compiling exactly the same code that works on 64 bits. I'm only changing -m32 -march-i386 for compiler and -m32 for linker.

$ ldd /usr/games/quake4/quake4.x86
    linux-gate.so.1 =>  (0xf774b000)
    /usr/lib32/openglhack32.so (0xf7746000) <-------- LOOK AT THIS IS IMPLEMENTED VIA LD_PRELOAD
    libSDL-1.2.so.0 => /usr/lib32/libSDL-1.2.so.0 (0xf7690000)
    libpthread.so.0 => /lib32/libpthread.so.0 (0xf7676000)
    libdl.so.2 => /lib32/libdl.so.2 (0xf7672000)
    libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7555000)
    libXext.so.6 => /usr/lib32/libXext.so.6 (0xf7545000)
    libz.so.1 => /usr/lib32/libz.so.1 (0xf7530000)
    libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7445000)
    libm.so.6 => /lib32/libm.so.6 (0xf741e000)
    libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7402000)
    libc.so.6 => /lib32/libc.so.6 (0xf72a7000)
    libGL.so.1 => /usr/lib32/nvidia-current/libGL.so.1 (0xf71de000)
    libasound.so.2 => /usr/lib32/libasound.so.2 (0xf7118000)
    librt.so.1 => /lib32/librt.so.1 (0xf710e000)
    /lib/ld-linux.so.2 (0xf774c000)
    libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf70f4000)
    libnvidia-tls.so.260.19.06 => /usr/lib32/nvidia-current/tls/libnvidia-tls.so.260.19.06 (0xf70f2000)
    libnvidia-glcore.so.260.19.06 => /usr/lib32/nvidia-current/libnvidia-glcore.so.260.19.06 (0xf5a55000)
    libXau.so.6 => /usr/lib32/libXau.so.6 (0xf5a51000)
    libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf5a4a000)

I noticed that the library appears on the list because I used LD_PRELOAD. But it still seem not to work, I guess because the code is not correct or something similar, because the speedhack works.

Yes, the 100% of programs (I've tested) are 64 bit working and 32 bit failing.

Thank you for your interest again.

30

Compiling as C++ pulls in a whole bunch of extra symbols and libraries even when you don't use them. I'm not sure whether there's any interfering symbols or not.

Hm. What other flags are there? Everything seems to use -fPIC for x86_64 but in 32-bit you see that less.

Beyond that I'm running out of suggestions. I had a strong suspicion your programs were using a different version of libc than the games were, but that seems to be wrong... I wish the dynamic loader's error messages weren't so cryptic.