dylib是MacOS上的动态库扩展,但我从来不清楚什么时候不能/不应该使用传统的Unix.so共享对象.
我有一些问题:
- 在概念层面上,两者的主要区别是什么.等等.dylib?
- 我什么时候可以/应该使用其中一种?
- 编译技巧&;提示(例如,替换gcc-shared-fPIC,因为这在osx上不起作用)
dylib是MacOS上的动态库扩展,但我从来不清楚什么时候不能/不应该使用传统的Unix.so共享对象.
我有一些问题:
Mac OS X用于可执行文件和库的Mach-O对象文件格式在shared libraries和dynamically loaded modules之间有区别.使用otool -hv some_file
查看some_file
的文件类型.
Mach-O共享库的文件类型为100,并带有扩展名.迪利布.它们可以通过常用的静态链接器标志进行链接,例如-lfoo
代表libfoo.迪利布.可以通过将-dynamiclib
标志传递给编译器来创建它们.(-fPIC
是默认值,无需指定.)
可加载模块在Mach-O语言中称为"Bundle ".他们的文件类型是100.它们可以携带任何分机;扩展.bundle
是苹果公司推荐的,但为了兼容性,大多数移植软件使用.so
.通常,您将使用plug-ins的Bundle 包来扩展应用程序;在这种情况下,bundle将与应用程序二进制文件链接,以访问应用程序导出的API.可以通过将-bundle
标志传递给编译器来创建它们.
dylib和Bundle 包都可以使用dl
个API(例如dlopen
、dlclose
)动态加载.不可能链接到包,就好像它们是共享库一样.但是,Bundle 包可能链接到真正的共享库;这些库将在加载Bundle 包时自动加载.
从历史上看,这种差异更为显著.在MacOSX10.0中,无法动态加载库.10.1中引入了一组DYLDAPI(例如NSCreateObjectFileImageFromFile
、NSLinkModule
)来加载和卸载包,但它们不适用于dylib.在10.3中添加了使用包的dlopen
兼容库;在10.4中,dlopen
被重写为DYLD的本机部分,并添加了对加载(但不是卸载)dylib的支持.最后,10.5添加了对结合使用dlclose
和dylib的支持,并弃用了DYLD API.
在像Linux,both use the same file format这样的ELF系统上,任何一段共享代码都可以用作库和动态加载.
最后,请注意,在MacOSX中,"bundle"可以also引用具有标准化 struct 的目录,该目录包含可执行代码和该代码使用的资源.概念上有一些重叠(特别是与插件之类的"可加载Bundle 包",它们通常包含Mach-OBundle 包形式的可执行代码),但不应将它们与上面讨论的Mach-OBundle 包混淆.
其他参考资料: