Si è corretto in che glibc utilizza il controllo delle versioni dei simboli. Se sei curioso, l'implementazione del versioning dei simboli introdotta in glibc 2.1 è descritta nello here ed è un'estensione dello schema di versioning dei simboli di Sun descritto here.
Un'opzione consiste nel collegamento statico del file binario. Questa è probabilmente l'opzione più semplice.
Si potrebbe anche costruire il vostro binario in un ambiente di generazione chroot, o utilizzando un glibc- nuova => glibc- vecchia cross-compilatore.
Secondo il post http://www.trevorpounds.com blog Linking to Older Versioned Symbols (glibc), è possibile forzare qualsiasi simbolo per essere collegato contro una più vecchia finché è valido utilizzando il medesimo .symver pseudo-op che viene utilizzato per definire con versione simboli in primo luogo. Il seguente esempio è tratto da blog post.
L'esempio seguente utilizza il percorso reale di glibc, ma si assicura che sia collegato a una versione 2.2.5 precedente.
#include <limits.h>
#include <stdlib.h>
#include <stdio.h>
__asm__(".symver realpath,[email protected]_2.2.5");
int main()
{
char* unresolved = "/lib64";
char resolved[PATH_MAX+1];
if(!realpath(unresolved, resolved))
{ return 1; }
printf("%s\n", resolved);
return 0;
}
Argh questo è uno di quei fastidiosi problemi di linux come dove la soluzione è sempre "non dovresti farlo", che ovviamente significa "non funziona e nessuno l'ha ancora risolto". – Timmmm
Le persone si sono lamentate dell'inferno DLL su Windows. Ricordo che Linux * alcuni * appassionati cercavano di farlo apparire come un esempio particolarmente orribile dal mondo Windows. Quando mi sono imbattuto per la prima volta in * questo * sviluppo di Linux oltre un decennio fa, tutto quello che ho fatto è stato seppellire la mia faccia tra le mie mani. – 0xC0000022L