gcc/LD - crear una nueva libc.so con __isoc99_sscanf @@ GLIBC_2.7 símbolo de glibc.2.6

Question

Tengo una aplicación, lo que hace un error al intentar ejecutarlo:

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

Pero el único símbolo que necesita de glibc 2.7 es

__isoc99_sscanf@@GLIBC_2.7 

Quiero escribir un pequeño sencillo "biblioteca" función con este símbolo como alias para __sscanf()

¿Cómo puedo hacer esto con gcc/ld?

Mi variante no es aceptada porque "@@" símbolos

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

segundo mi variante es

#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"); 

pero finaliza con un "nodo de la versión no encontrado para __isoc99_sscanf símbolo @@ GLIBC_2.7 "error del enlazador.

Answer 1

Encontré @felipec s respuesta muy útil. Además, nuestra aplicación tenía que hacer un enlace dinámico usando ocaml, y descubrimos que el script dado no funciona para este escenario, ya que hace que la aplicación solo exporte el símbolo __isoc99_sscanf como global.

GLIBC_2.7 { 
global: *; 
}; 

La secuencia de comandos anterior resuelve este problema y permite que el enlazador dinámico de ocaml funcione correctamente. el uso de la opción -D_GNU_SOURCE por sí solo no fue suficiente para evitar este problema ya que la dependencia de GLIBC_2.7 provenía de un binario preconstruido con el que estábamos enlazando estáticamente.

Answer 2

Su segunda versión funciona con este script:

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

Usando -Wl,--version-script=script.txt, sin embargo, que no saben cómo acceder a los originales sscanf@GLIBC_2.4.

En cualquier caso, quizás desee utilizar -D_GNU_SOURCE en su lugar; para evitar __isoc99_sscanf en total.