lib {library name} .a/.so是Linux中静态库的命名约定吗? [英] Is lib{library name}.a / .so a naming convention for static libraries in Linux?

问题描述

最近，我不得不在Ubuntu系统上做一些次要的编程(在这个系统上我是一个非常低级的初学者)，我真的只是对makefile很熟悉.

我注意到，告诉链接程序要包括哪些库的参数始终为-l {library name}，其中在/usr/lib文件夹中相应的库将是名为"lib {library name} .a"的内容. /p>

我想知道:这是公约吗?我本以为我需要键入-llibNAME来找到一个名为libNAME.a的库，但它似乎采用了lib前缀.

总是这样吗?我可以在不使用lib前缀的情况下命名库吗?

解决方案

您可以随意命名，但是ld的-l假定lib前缀适用于静态库和共享库，并且向后退很长一段路您需要明确命名它，以使用不带lib前缀的一个.

这实际上甚至在现代系统上也很有用:名称libfoo.so可以标识为链接时库，而foo.so表示实现运行时插件的共享对象.或使用子系统特定的前缀代替lib来标识特定子系统的插件；参见例如pam_*.so和nss_*.so.

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?

解决方案

You can name one any way you want, but ld's -l assuming a lib prefix 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 lib prefix.

This is actually useful even on modern systems: a name libfoo.so can be identified as a link-time library, while foo.so indicates a shared object implementing a runtime plugin. Or subsystem-specific prefixes in place of lib to identify plugins for particular subsystems; see for example pam_*.so and nss_*.so.

这篇关于lib {library name} .a/.so是Linux中静态库的命名约定吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！