lib{库名}.a / .so 是 Linux 中静态库的命名约定吗？
最近我不得不在 Ubuntu 系统上进行一些小型编程（我是一个非常低级的初学者），而且我真的只是在熟悉 makefile。
我注意到告诉链接器要包含哪些库的参数始终是 -l{库名称}，其中相应的库在 /usr/lib 文件夹中称为“lib{库名称}.a”。
我想知道：这是一个约定吗？我本以为我需要输入 -llibNAME 来查找名为 libNAME.a 的库，但它似乎假定有一个 lib 前缀。
情况总是如此吗？我可以在不使用 lib 前缀的情况下命名库吗？
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.
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.
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.
Is this always the case? Can I name a library without using a lib prefix?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以以任何您想要的方式命名一个，但
ld的-l假设lib前缀适用于静态库和共享库并返回很长一段路；您需要显式命名它才能使用不带lib前缀的名称。即使在现代系统上，这实际上也很有用：名称
libfoo.so可以被识别为链接时库，而foo.so表示实现运行时插件的共享对象。或者使用特定于子系统的前缀来代替 lib 来标识特定子系统的插件；例如，请参阅pam_*.so和nss_*.so。You can name one any way you want, but
ld's-lassuming alibprefix applies to both static and shared libraries and goes back a long way; you'd need to name it explicitly to use one without thelibprefix.This is actually useful even on modern systems: a name
libfoo.socan be identified as a link-time library, whilefoo.soindicates a shared object implementing a runtime plugin. Or subsystem-specific prefixes in place oflibto identify plugins for particular subsystems; see for examplepam_*.soandnss_*.so.name.a是一个静态库（a因为它是对象的存档）。name.so是一个动态库（so因为它是一个共享对象，有时也称为 DSO，即动态共享对象）。-lfoo链接器开关传统上采用libfoo.{so,a}形式的名称，并在库路径上搜索它。您还可以直接将库名称传递给链接器（不使用-l开关），但在这种情况下，您必须显式传递库的路径。正如 @geekosaur 指出的，如果您在运行时打开共享对象，则 dlopen() 会获取完整的文件名。
name.ais a static library (abecause it's an archive of objects).name.sois a dynamic library (sobecause it's a shared object, also sometimes known as a DSO, for Dynamic Shared Object).The
-lfoolinker switch traditionally assumes a name of the formlibfoo.{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.As
@geekosaurnoted, if you open a shared object at runtime,dlopen()takes the full filename.简短的回答，是的，这是惯例。
g++ 的 -l 选项将检查 lib 和本地路径中的 lib{somename}.so 。
然而在 UNIX 中，您还可以使用符号链接，这样您就可以拥有不同版本的库，而无需修改 make 脚本。
编辑添加：
正如有人在评论中指出的那样，
.a是静态库的扩展名，而.so是共享库。Short answer, yes that is the convention.
g++'s -l option will check for lib{somename}.so in your lib and local paths.
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.
edit to add:
As someone pointed out in the comment,
.ais the extension for a static library, while.sois a Shared library.事实上，不。我的意思是，几乎！您将静态库与共享库混合在一起。静态库是
.a文件，共享库以.so结尾。总而言之，您正在谈论共享库，好吗？将应用程序与共享库链接时，您需要使用标准约定，即
-lNAME，其中 NAME 属于 libNAME.soActually, no. I mean, almost! You are mixing static libraries with shared libraries. Static libraries are
.afiles, and shared libraries end with.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 NAME belongs to libNAME.so