创建一个新的libc。所以用__isoc99_sscanf@gglibc_2.7符号从glibc.2.6中。

时间:2021-11-10 05:38:43

I have an application, which does a error when I try to run it:

我有一个应用程序,当我试图运行它时它会出错:

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

But the only symbol it needs from glibc 2.7 is

但glibc 2.7唯一需要的符号是。

__isoc99_sscanf@@GLIBC_2.7 

I want to write a small single function "library" with this symbol as alias to __sscanf()

我想用这个符号来写一个小的函数“库”,作为__sscanf()的别名

How can I do this with gcc/ld?

我该如何使用gcc/ld呢?

My variant is not accepted because "@@" symbols

我的变体不被接受,因为“@@”符号。

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

second my variant is

第二我的变体

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

but it ends with "version node not found for symbol __isoc99_sscanf@@GLIBC_2.7" error from linker.

但是它的结尾是“版本节点没有找到符号__isoc99_sscanf@glibc_2.7”链接错误。

2 个解决方案

#1


2  

I found @felipecs answer very helpful. In addition our application had to do some dynamic linking using ocaml, and we found that the given script doesn't work for this scenario, since it makes the application only export the __isoc99_sscanf symbol as a global.

我发现@felipecs的回答很有帮助。此外,我们的应用程序还必须使用ocaml做一些动态链接,我们发现这个脚本在这个场景中不起作用,因为它使应用程序只导出__isoc99_sscanf符号作为全局变量。

GLIBC_2.7 {
 global: *;
};

the above script resolves this issue and allows ocaml's dynamic linker to work properly. using the -D_GNU_SOURCE option alone wasn't enough to avoid this issue since the dependency on GLIBC_2.7 came from a prebuilt binary we were statically linking with.

上面的脚本解决了这个问题,并允许ocaml的动态链接器正常工作。仅使用-D_GNU_SOURCE选项还不足以避免这个问题,因为GLIBC_2.7的依赖来自于我们静态链接的预构建的二进制文件。

#2


4  

Your second version works with this script:

您的第二个版本与这个脚本一起工作:

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

Using -Wl,--version-script=script.txt, however, I don't know how to access the original sscanf@GLIBC_2.4.

使用- wl - version-script =脚本。但是,我不知道如何访问原始的sscanf@GLIBC_2.4。

Anyway, perhaps you would want to use -D_GNU_SOURCE instead; to avoid __isoc99_sscanf altogether.

不管怎样,也许您希望使用-D_GNU_SOURCE;完全避免__isoc99_sscanf。

#1


2  

I found @felipecs answer very helpful. In addition our application had to do some dynamic linking using ocaml, and we found that the given script doesn't work for this scenario, since it makes the application only export the __isoc99_sscanf symbol as a global.

我发现@felipecs的回答很有帮助。此外,我们的应用程序还必须使用ocaml做一些动态链接,我们发现这个脚本在这个场景中不起作用,因为它使应用程序只导出__isoc99_sscanf符号作为全局变量。

GLIBC_2.7 {
 global: *;
};

the above script resolves this issue and allows ocaml's dynamic linker to work properly. using the -D_GNU_SOURCE option alone wasn't enough to avoid this issue since the dependency on GLIBC_2.7 came from a prebuilt binary we were statically linking with.

上面的脚本解决了这个问题,并允许ocaml的动态链接器正常工作。仅使用-D_GNU_SOURCE选项还不足以避免这个问题,因为GLIBC_2.7的依赖来自于我们静态链接的预构建的二进制文件。

#2


4  

Your second version works with this script:

您的第二个版本与这个脚本一起工作:

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

Using -Wl,--version-script=script.txt, however, I don't know how to access the original sscanf@GLIBC_2.4.

使用- wl - version-script =脚本。但是,我不知道如何访问原始的sscanf@GLIBC_2.4。

Anyway, perhaps you would want to use -D_GNU_SOURCE instead; to avoid __isoc99_sscanf altogether.

不管怎样,也许您希望使用-D_GNU_SOURCE;完全避免__isoc99_sscanf。