Kompilierte Bibliothek mit einer neueren Version von glibc verknüpfen

9

Ich arbeite an einem Projekt, das die FTDI D2XX Treiber benutzt, um mit dem ENTTEC DMX USB Pro Gerät zu kommunizieren. Die FTDI-Treiber (libftdi2xx.so.1.1.12, gespeichert in / usr / local / lib /) werden mit einer Version von glibc v2.14 oder höher kompiliert.

Ich entwickle auf debian 7, das nur bis glibc v2.13 unterstützt. Beim Ausführen des C-Codes, den ich geschrieben habe (der Aufrufe an die FTDI-Treiber), gibt es einen Fehler:

%Vor%

Dies macht Sinn, wenn man weiß, dass die glibc-Version inkompatibel ist. Ich habe die neueste Version von glibc (v2.17) in ein temporäres Verzeichnis ('~ / glibc-testing / install / lib /') heruntergeladen und auf meinem Computer installiert und den Aufruf verwendet:

%Vor%

Mit diesem Aufruf kann ich den C-Code erfolgreich ausführen.

Ich möchte diesen C-Code in einer gemeinsam genutzten Bibliothek kompilieren. Es wird für die Verbindung mit dem DMX-Gerät verwendet und wird von einer Hauptanwendung aufgerufen, die auf C # entwickelt wurde.

Ich bin nicht sicher, wie ich vorwärts gehen soll. Ich muss dem fdti-Treiber mitteilen, dass er immer die neuere glibc verwenden soll, während der Rest der Anwendung die normalen Bibliotheken verwenden soll. Die FTDI 2DXX-Treiber sind nur vorkompiliert (kein Quellcode verfügbar). Gibt es eine Möglichkeit, dieses vorkompilierte Programm mit der neuen Bibliothek zu verknüpfen?

Ich habe nach Möglichkeiten gesucht, wo ich LD_LIBRARY_PATH = / home /.../ glibc / install / lib / exportiert habe und ich hatte wenig Erfolg.

Danke!

    
Brotherhood 18.02.2013, 06:50
quelle

3 Antworten

1

Sie können die fehlenden Funktionen in Ihrem eigenen Code bereitstellen, beachten Sie jedoch, dass diese versioniert sind. Sie können entweder eine Map-Datei bereitstellen oder alles zusammen mit dem Code ausführen. Beispiel:

%Vor%

Um herauszufinden, was zu implementieren ist, können Sie readelf:

verwenden %Vor%

Das ist es soweit Funktionen funktionieren.

Jetzt ist der knifflige Teil, dass der Loader glaubt, dass er die richtige Bibliothek hat (es sei denn, Sie wollen einen eigenen Loader implementieren), dafür müssen Sie die Bibliothek patchen, um den Verweis auf GLIBC_2.14 zu entfernen, weil es geht speziell auf die libc schauen.

Es gibt mehrere Möglichkeiten, um fortzufahren; Bei weitem die einfachste ist, GLIBC_2.14 durch GLIBC_2.13 zu ersetzen, denken Sie daran, dass Sie Ihre Symbole mit der Ersetzung Version (dh GLIBC_2.13 ) definieren müssen, da Versionen als Referenz gespeichert werden .

Damit sollte Ihr Programm laufen.

Nun, theoretisch könntest du stattdessen:

  • Analysiere die ELF-Datei, finde den Eintrag DYNAMIC type im Programm Header, dort suchen Sie nach einem VERNEED -Eintrag und schließlich folgen Sie sollten die Tabelle der Anforderungen finden, wo Sie schneiden können die Referenz (Sie können auch den Header .gnu.version_r verwenden um dorthin zu gelangen, falls verfügbar.)

  • Alternativ könnten Sie einen Loader schreiben, der den Standard kettet loader, verwendet jedoch ptrace , um die Suche zu überschreiben.

Ismael Luceno 23.09.2016 08:11
quelle
0

eine der Varianten es ist debian zu sid aktualisieren.

Eine weitere Möglichkeit besteht darin, die Datei /etc/ld.so.conf.d/libc.conf und /etc/ld.so.conf.d/x86_64-linux-gnu.conf

zu ändern

Diese Dateien enthalten den Pfad zur Suche nach Bibliotheken im System.

    
Ivan Ivanovich 01.10.2014 19:14
quelle
0

Sie können PatchELF verwenden, um den rpath der bereitgestellten gemeinsam genutzten Bibliothek zu ändern:

%Vor%

Und dann kompilieren Sie Ihre gemeinsame Bibliothek mit:

%Vor%

Alle ausführbaren Dateien, die Sie kompilieren, müssen mit:

kompiliert werden %Vor%     
Mikel Rychliski 31.03.2016 17:49
quelle

Tags und Links