gcc/LD - utworzyć nową libc.so z __isoc99_sscanf @@ GLIBC_2.7 symbol z glibc.2.6

Question

Mam aplikacji, która robi błąd, gdy próbuję go uruchomić:

/lib/libc.so.6: version `GLIBC_2.7' not found 

Ale tylko symbol potrzebuje od glibc 2.7 jest

__isoc99_sscanf@@GLIBC_2.7 

Chcę napisać mały jednofunkcyjny "biblioteka" z tym symbolem jako alias do __sscanf()

jak mogę to zrobić z gcc/LD?

Mój wariant nie jest akceptowana, ponieważ "@@" symboli

int __isoc99_sscanf@@GLIBC_2.7(const char *, const char *, ...) __attribute__((alias("__sscanf"))); 

sekunda mój wariant jest

#include <stdarg.h> 
int __isoc99_sscanf1(const char *a, const char *b, va_list args) 
{ 
    int i; 
    va_list ap; 
    va_copy(ap,args); 
    i=sscanf(a,b,ap); 
    va_end(ap); 
    return i; 
} 

    // __asm__(".symver __isoc99_sscanf,__isoc99_sscanf@@GLIBC_2.7"); 
    __asm__(".symver __isoc99_sscanf1,__isoc99_sscanf@@GLIBC_2.7"); 

ale kończy z „Wersja węźle nie znaleziono dla symbolu __isoc99_sscanf @@ GLIBC_2.7 "błąd z linkera.

Answer 1

Znalazłem odpowiedź @felipec s bardzo pomocne. Dodatkowo nasza aplikacja musiała wykonać dynamiczne łączenie za pomocą programu ocaml i okazało się, że dany skrypt nie działa w tym scenariuszu, ponieważ powoduje, że aplikacja eksportuje tylko symbol __isoc99_sscanf jako globalny.

GLIBC_2.7 { 
global: *; 
}; 

Powyższy skrypt rozwiązuje ten problem i pozwala SML za dynamiczny linker działał poprawnie. użycie samej opcji -D_GNU_SOURCE nie wystarczyło, aby uniknąć tego problemu, ponieważ zależność od GLIBC_2.7 pochodziła z wstępnie skonstruowanego pliku binarnego, z którym łączyliśmy się statycznie.

Answer 2

Twoja druga wersja działa z tego skryptu:

GLIBC_2.7 { 
global: __isoc99_sscanf; 
local: *; 
}; 

Korzystanie -Wl,--version-script=script.txt, jednak nie wiem, jak uzyskać dostęp do oryginalnego sscanf@GLIBC_2.4.

Zamiast tego, być może zechcesz zamiast tego użyć -D_GNU_SOURCE; aby w ogóle uniknąć __isoc99_sscanf.