2017-12-02 10 views
1

Ich möchte eine alte Software verwenden (Unreal Tournament "Classic" von 1999, auch bekannt als UT99). Die dynamische Bibliothek libtxc_dxtn.so wird implizit geladen und sucht nach der Unterstützung für die S3-Texturkomprimierung (S3TC). Leider stürzt die Hauptanwendung beim Laden der Bibliothek mit einem Segmentierungsfehler ab (Crash auch beschrieben here). Eine Problemumgehung scheint das Entfernen der Texturkomprimierungsbibliothek für Mesa durch Löschen oder Verschieben von libtxc_dxtn.so. Die Anwendung läuft perfekt ohne Texturkomprimierung, aber natürlich sind andere Anwendungen, die die Unterstützung der Texturkomprimierung verlangen, jetzt defekt. Natürlich möchte ich mein System nicht für eine bestimmte Anwendung ändern.So verhindern Sie, dass eine bestimmte dynamische Bibliothek geladen wird

Also meine Frage ist:
Kann ich verhindern (wie in "Maske" oder "deaktivieren") eine bestimmte dynamische Bibliothek von einer bestimmten Anwendung geladen werden? Ich hoffe, etwas wie das Gegenteil von LD_PRELOAD zu finden.

aktualisieren: libtxc_dxtn.so ist implizit und indirekt geladen. Das Ändern der Anwendungsbinärdatei ist nicht möglich.

initialize program: ut-bin 
file=libSDL-1.1.so.0 [0]; needed by ut-bin [0] 
file=libGL.so.1 [0]; dynamically loaded by libSDL-1.1.so.0 [0] 
file=i965_dri.so [0]; dynamically loaded by libGL.so.1 [0] 
file=libtxc_dxtn.so [0]; dynamically loaded by i965_dri.so [0] 
+0

Was meinst du _indirectly loaded_? 'dlopen()'? Wenn ja, könnten Sie vielleicht 'LD_PRELOAD' eine' dlopen() 'überschreiben, die' libtxc_dxtn.so' nicht durchschaltet. – PSkocik

+0

Ja, 'dlopen()' wird verwendet. Mit "indirekt geladen" meine ich, dass "die Bibliothek nicht von der Anwendung selbst geladen wird, sondern von einer gemeinsam genutzten Bibliothek, die wiederum von der Anwendung geladen wird". In meinem Fall ist es "Anwendung" → "libSDL-1.1.so.0" → "libGL.so.1" → "i965_dri.so" → "libtxc_dxtn.so". Nur die erste Bibliothek wird als Abhängigkeit geladen, die anderen werden mit 'dlopen()' geladen. – Hermann

+0

Der 'LD_PRELOAD' eines' dlopen' Override-Ansatzes sollte funktionieren (solange die abhängigen Bibliotheken nicht 'RTLD_LOCAL' verwenden, aber das ist ein veraltetes Nicht-Standard-Flag, das sowieso nicht verwendet werden sollte). Ich habe meine Antwort aktualisiert. – PSkocik

Antwort

2

Es gibt ein Dienstprogramm genannt, die Ihnen die DSO Abhängigkeit von der ausführbaren Datei zu entfernen, ermöglichen soll.

Hier ist ein Beispiel, das eine libpthread Abhängigkeit von einer Dummy-ausführbaren entfernt:

echo 'int main(){}' | 
    gcc -x c - -Wl,--no-as-needed -lpthread && 
    ldd a.out && 
    patchelf --remove-needed libpthread.so.0 a.out && 
    echo ====== && 
    ldd a.out 

Meine Ausgabe:

linux-vdso.so.1 => (0x00007ffeced67000) 
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f21560f1000) 
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2155d28000) 
    /lib64/ld-linux-x86-64.so.2 (0x00007f215630f000) 
====== 
    linux-vdso.so.1 => (0x00007fffac536000) 
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6235c0d000) 
    /lib64/ld-linux-x86-64.so.2 (0x00007f6235fd6000) 

Update:

Wenn libtxc_dxtn.so mit dlopen geladen, Sie kann eine Minibibliothek, diebereitstellt, vorab laden (LD_PRELOAD)Override, das NULL zurückgibt, wenn sein Dateiname Argument ist z. B. "libtxc_dxtn.so" (ltrace sollte Ihnen helfen, zu finden, welche Argumente tatsächlichen Dateinamen müssen Sie schützen). Etwas wie:

#define _GNU_SOURCE 
#include <dlfcn.h> 
#include <string.h> 

void *dlopen(char const *Fnm, int Flg) 
{ 
    void *(*real_dlopen)(char const *, int); 
    *(void**)(&real_dlopen) = dlsym(RTLD_NEXT, "dlopen"); 
    if(0==strcmp("libtxc_dxtn.so", Fnm)){ 
     return NULL; 
    }else{ 
     return real_dlopen(Fnm, Flg); 
    } 

} 
+1

Ich fügte hinzu, dass 'Fnm' NULL ist und übertrage den Aufruf auch auf' real_dlopen'. Jetzt funktioniert das großartig. Ich danke Ihnen für Ihre sehr ausführliche Antwort. – Hermann

+0

Für die Aufzeichnung, https://stackoverflow.com/questions/6083337/overriding-malloc-use-the-ld-preload-mechanism war auch in dieser Hinsicht hilfreich. – Hermann

Verwandte Themen