一尘不染

Clang / GCC是否真的支持延迟加载功能?

linux

如果您 确实经历过
与上述标题相关的事情,您是否愿意对此发表评论?我试图使共享对象在Ubuntu上同时被Clang和GCC延迟加载(我实际上不介意使用哪个编译器),但是它们看起来并没有真正支持任何延迟加载功能(我期望延迟加载功能)在需要此功能时,将存根放在父对象中,该对象试图按需加载另一个对象,但实际上并不需要)。以下命令显示了我试图使libbar.so被延迟加载到libfoo.so:

clang bar.c -fPIC -shared -o libbar.so
clang foo.c -Wl,-zlazy,lL'/path/to/where/lib/is',-lbar -o foo

如果libbar.so不存在,您将看到libfoo.so在进入条目之前引发异常。无论如何,我不介意上面的命令中是否有任何拼写错误,但想知道 Clang
/ GCC是否确实支持延迟加载功能

但是,就个人而言,如果Clang /
GCC不支持任何延迟加载功能,我是否相信Linux程序开发人员是否需要调用dlopen()或dlsym()来使共享库延迟加载。如果对象是用C编写的就可以了,但是如果对象是用C
++编写的,则情况必须非常复杂:(

我相信在编译器或链接器的帮助下实现的解决方案是最好的,因为我已经在Windows和Mac OS上成功完成了该解决方案。因此,我觉得公民即使梦想在Clang
/ GCC上也梦想拥有延迟加载功能,这将是一种自然的反应。如果您对我的感受有任何评论,我也将不胜感激。

PS。我知道Solaris支持延迟加载功能,但是这对我来说不是可行的方法,因为我不会对此进行任何开发。

无论如何,非常感谢您。


阅读 310

收藏
2020-06-03

共1个答案

一尘不染

这更多是运行时链接程序ld-linux.so提供的功能问题。

此链接器确实支持符号的延迟绑定,但不支持库的延迟加载。这意味着在程序启动时会加载可执行文件所需的每个共享库,但是直到程序中的符号在第一次被引用之前,它们都不会解析到加载的库中。

原因是性能。一个库可能包含数千个函数的符号,这些符号在程序的一次执行中就不会被调用。解决所有这些问题将浪费时间。

因此,如果库中不包含预期的符号,则在程序开始运行后很容易会出现“未定义符号”错误,但如果完全缺少库,则在程序启动之前会出现错误。

-zlazy您引用的选项仅控制惰性符号绑定。实际上,默认情况下它是启用的(至少对于GCC,我没有检查clang)。

程序启动后(例如,响应某些命令行选项,配置或其他动态情况),加载库的唯一方法是调用dlopen

2020-06-03