动态加载静态库?
Can a static libary *.a
in Linux be dynamically loaded at runtime?
I've read here that
...both static and shared libraries can be used as dynamically loaded libraries.
How to dynamically load static library?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
静态库或多或少只是目标文件的集合。如果要在程序中使用静态库,则必须将可执行文件与其链接。然后,可执行文件将包含静态库(或您使用的部分)。
如果您想使用 dlopen 在运行时加载静态库,则必须首先创建包含它的动态库 libfoo.so 。
A static library is more or less just a collection of object files. If you want to use a static library in a program, you have to link the executable with it. The executable will then contain the static library (or the parts that you used).
If you want to load a static library at runtime using
dlopen
, you will have to first create a dynamic librarylibfoo.so
containing it.使用
dlopen
打开.a
文件不起作用(在 Ubuntu 10.04 上测试)。使用以下示例程序:我得到:
当使用
/usr/lib/libz.so
时,我得到:所以相同的代码适用于共享对象。
Opening a
.a
file usingdlopen
does not work (tested on Ubuntu 10.04). With the following example program:I get:
while when using
/usr/lib/libz.so
instead, I get:so the same code works for a shared object.
.a 是包含一个或多个 .o elf 对象的存档。 Readelf 和 objdump 不会解析它们。您必须使用 ar 从存档中提取 .o 文件。重要的是要认识到,如果您愿意花时间编写和调试可以将一个或多个静态库包装在 HAL 中的 load_elf() 变体,您可以动态加载它们并为客户端提供一种内省其调用入口的方法点。这是不标准的,我已经能感觉到文人像行走的杰德一样抽搐了。然而,ELF 包含足够的信息,可以将库放入运行时环境中,并为正确编码的客户端函数提供一种发现所提供函数的接口并调用它们的方法。这不是火箭科学。这实在是太乏味了。这里的一个重要概念是,提供 .a 存档和包含套件的开发人员认为它们会限制您对库的使用,这只是令人烦恼。这并不是使用该库或发现它如何工作的严重障碍。
A .a is an archive containing one or more .o elf objects. Readelf and objdump won't parse them. You must use ar to xtract the .o files from the archive. It is important to realize that if you are willing to spend the time writing and debugging a variant of load_elf() that can wrap one or more static libraries in a HAL you can load them dynamically and provide clients with a way to introspect their call entry points. This is nonstandard, and I can already feel the literati twitching like The Walking Jed. However, the ELF contains enough information to drop a library into a runtime environment and give properly coded client functions a way to discover the interface to the functions provided, and call them. This isn't rocket science. It is simply tedious. An important concept here is that a developer who provides the .a archive and a include suite with the idea that they are restricting your use of the libraries, is just being annoying. It is not a serious impediment to using the library, or discovering how it does it's job.