Collegamento della libreria compilata alla versione più recente di glibc

Question

Sto lavorando a un progetto che utilizza i driver ftdi D2XX per interfacciarsi con il dispositivo ENTTEC DMX usb pro. I driver ftdi (libftdi2xx.so.1.1.12 memorizzati in/usr/local/lib /) sono compilati su una versione di glibc v2.14 o successiva.

Sto sviluppando su debian 7 che supporta solo fino a glibc v2.13. Quando si esegue il codice C che ho scritto (che effettua le chiamate al driver FTDI) dà un errore:

./a.out: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /usr/local/lib/libftd2xx.so) 

Questo ha senso, sapendo che la versione glibc è incompatibile. Ho scaricato e installato l'ultima versione di glibc (V2.17) in una directory temporanea ('~/glibc-testing/install/lib /') sul mio computer e utilizzando la chiamata:

~/glibc-testing/install/lib/ld-linux-x86-64.so.2 --library-path ~/glibc-testing/install/lib/ ./a.out 

Con questa chiamata, sono in grado di eseguire correttamente il codice C.

Vorrei compilare questo codice C in una libreria condivisa. Verrà utilizzato per interfacciarsi con il dispositivo DMX e verrà chiamato da un'applicazione principale sviluppata su C#.

Non so come andare avanti. Quello che sembra che devo fare è dire al driver fdti di usare sempre gli ultimi glibc mentre lascia che il resto dell'applicazione usi le normali librerie. I driver ftdi 2DXX sono disponibili solo precompilati (nessun codice sorgente disponibile). C'è un modo per collegare questo programma precompilato alla nuova libreria?

Ho esaminato le opzioni in cui esporto LD_LIBRARY_PATH =/home /.../ glibc/install/lib/e ho avuto scarso successo.

Grazie!

Answer 1

una delle varianti è aggiornamento debian a sid.

un'altra opzione è quella di modificare il file /etc/ld.so.conf.d/libc.conf e /etc/ld.so.conf.d/x86_64-linux-gnu.conf

Questi file contengono il percorso di ricerca per le biblioteche del sistema.

Answer 2

È possibile utilizzare PatchELF per modificare il rpath della libreria condivisa a condizione che:

$ patchelf --set-rpath /home/user/glibc-testing/install/lib/ libftdi2xx.so.1.1.12 

e quindi compilare la libreria condivisa utilizzando:

$ gcc -Wl,-rpath=/home/user/glibc-testing/install/lib/ <rest of flags> 

Qualsiasi eseguibili si compila dovrà essere compilato con :

$ gcc -Wl,-rpath=/home/user/glibc-testing/install/lib/ -Wl,--dynamic-linker=/home/user/glibc-testing/install/lib/ld-linux-x86-64.so.2 <rest of flags> 

Answer 3

È possibile fornire le funzioni mancanti nel proprio codice, ma si noti che sono versioni, è possibile fornire un file di mappa o fare tutto insieme con il codice. Esempio:

#define SYMVER(ver, sym) __asm__(".symver " #sym "," #sym "@" #ver "\n") 

SYMVER(GLIBC_2.14, foo); 
int foo(int a, char *b) 
{ 
    return 4; 
} 

Al fine di capire cosa implementare, è possibile utilizzare readelf:

readelf -s /usr/local/lib/libftd2xx.so | grep '@GLIBC_2\.14' 

Questo è tutto, per quanto riguarda le funzioni di andare.

Ora la parte difficile è far credere al caricatore di aver ottenuto la libreria corretta (a meno che non si voglia implementare il proprio caricatore), per questo è necessario patteggiare la libreria per rimuovere il riferimento a GLIBC_2.14, perché sta per guarda specificamente la libc.

Ci sono diversi modi per procedere; il più semplice è sostituire GLIBC_2.14 con GLIBC_2.13, basti ricordare che è necessario definire i simboli con la versione sostitutiva (ad esempio GLIBC_2.13), perché le versioni sono memorizzate per riferimento.

Con ciò il programma dovrebbe essere eseguito.

Ora, in teoria si potrebbe invece:

• analizzare il file ELF, trovare le l'ingresso DYNAMIC tipo nel programma intestazioni, c'è la ricerca di una voce VERNEED, e, infine, a seguito che quello che si dovrebbe trova la tabella dei requisiti in cui è possibile ritagliare il riferimento per ottenere il riferimento (se disponibile).

• In alternativa, è possibile scrivere un caricatore che incatena il caricatore standard ma utilizza ptrace per sovrascrivere la ricerca.