lib{library name}.a / .so 是 Linux 中静态库的命名约定吗？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/6561273/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is lib{library name}.a / .so a naming convention for static libraries in Linux?
提问by 8bitcartridge
I've had to do some minor programming on a Ubuntu system recently (at which I am an extremely low-level beginner) and I'm really just getting familiar with makefiles.
我最近不得不在 Ubuntu 系统上做一些小编程（我是一个非常低级的初学者）而且我真的只是熟悉 makefile。
I noticed that the arguments to tell the linker which libraries to include were always -l{library name} where the corresponding library would be something called "lib{library name}.a" in the /usr/lib folder.
我注意到告诉链接器要包含哪些库的参数总是 -l{library name}，其中相应的库是 /usr/lib 文件夹中名为“lib{library name}.a”的东西。
I am wondering: is that a convention? I would have thought I would need to type -llibNAME to find a library called libNAME.a, but it seems to assume a lib prefix.
我想知道：这是约定吗？我原以为我需要输入 -llibNAME 才能找到一个名为 libNAME.a 的库，但它似乎假定了一个 lib 前缀。
Is this always the case? Can I name a library without using a lib prefix?
总是这样吗？我可以在不使用 lib 前缀的情况下命名库吗？
采纳答案by geekosaur
You can name one any way you want, but ld's -lassuming a libprefix applies to both static and shared libraries and goes back a long way; you'd need to name it explicitly to use one without the libprefix.
您可以命名一个你想要的任何方式，但ld的-l假设lib前缀适用于静态和共享库，并可以追溯到很长的路要走; 您需要明确命名它以使用没有lib前缀的名称。
This is actually useful even on modern systems: a name libfoo.socan be identified as a link-time library, while foo.soindicates a shared object implementing a runtime plugin. Or subsystem-specific prefixes in place of libto identify plugins for particular subsystems; see for example pam_*.soand nss_*.so.
即使在现代系统上，这实际上也很有用：名称libfoo.so可以识别为链接时库，同时foo.so表示实现运行时插件的共享对象。或子系统特定的前缀代替lib标识特定子系统的插件；参见例如pam_*.so和nss_*.so。
回答by Alan
Short answer, yes that is the convention.
简短的回答，是的，这是惯例。
g++'s -l option will check for lib{somename}.so in your lib and local paths.
g++ 的 -l 选项将检查 lib{somename}.so 在您的 lib 和本地路径中。
However in UNIX, you can also make use of symbolic links, so you can have different versions of libraries, without having to modify your make scripts.
但是在 UNIX 中，您也可以使用符号链接，因此您可以拥有不同版本的库，而无需修改您的 make 脚本。
edit to add:
编辑添加：
As someone pointed out in the comment, .ais the extension for a static library, while .sois a Shared library.
正如有人在评论中指出的那样，.a是静态库的扩展，.so而是共享库。
回答by karlphillip
Actually, no. I mean, almost! You are mixing staticlibraries with sharedlibraries. Static libraries are .afiles, and shared libraries end with .so.
实际上，没有。我的意思是，几乎！您正在将静态库与共享库混合。静态库是.a文件，共享库以.so.
To summarize, you're talking about shared libraries, ok? When linking your application with shared libs, you need to use the standard convention which is -lNAME, where NAMEbelongs to libNAME.so
总而言之，您在谈论共享库，好吗？将您的应用程序与共享库链接时，您需要使用标准约定-lNAME，即NAME属于libNAME.so
回答by ninjalj
name.ais a static library (abecause it's an archive of objects).
name.a是一个静态库（a因为它是一个对象档案）。
name.sois a dynamic library (sobecause it's a shared object, also sometimes known as a DSO, for Dynamic Shared Object).
name.so是一个动态库（so因为它是一个共享对象，有时也称为动态共享对象的 DSO）。
The -lfoolinker switch traditionally assumes a name of the form libfoo.{so,a}, and searches for it on the library path. You can also pass a library name to the linker directly (without using the -lswitch), but in that case you have to pass the path to the library explicitly.
该-lfoo连接器开关传统假设形式的名称libfoo.{so,a}，并在库路径上搜索它。您也可以直接将库名称传递给链接器（不使用-l开关），但在这种情况下，您必须明确地将路径传递给库。
As @geekosaurnoted, if you open a shared object at runtime, dlopen()takes the full filename.
如前所述@geekosaur，如果您在运行时打开共享对象，dlopen()则使用完整的文件名。
