与共享库链接时，什么被添加到可执行文件？

@H_502_0@如果我想创build一个与静态库链接的C ++程序，那么最终的可执行文件将同时包含来自我的程序的代码和库中的代码（我认为…！）。 但我不完全确定，当我与共享库链接时发生了什么。

@H_502_0@假设我通过在我的CMakeLists.txt文件中指定了target_link_libraries(${PROJECT_NAME} foo)来连接一个名为libfoo.so的库。 我假设最终的可执行文件将包含关于这个库的一些信息，但不是完整的代码。 这是什么信息？ 此外，图书馆是否必须在用户的系统上正确调用libfoo.so ？

@H_502_0@Windows API作业对象：不要传递给孙子们

@H_502_0@任何人都可以想到一个简单的方法来创build一个套接字的线程？

@H_502_0@编程一个通用的遥控器

@H_502_0@如何testing远程UDP端口

@H_502_0@CreateProcess后调用GetmodulefileNameEx时，ERROR_INVALID_HANDLE

@H_502_0@链接到动态库时，链接器将在程序的动态部分添加一个NEEDED条目。 然后动态加载器将使用这些来定位库，并使用库来解决任何未定义的动态符号。

@H_502_0@请注意，未定义的动态符号与动态库之间没有任何联系，因为这些动态库预计会被找到。 有时他们在另一个图书馆被发现，有趣的事情可能会发生。

@H_502_0@存储在NEEDED条目中的特定名称取决于库的动态部分是否有SONAME条目：

@H_502_0@如果有一个SONAME ，那么它的内容将被复制到程序的NEEDED中

@H_502_0@如果不存在SONAME ，则链接器命令中使用的库的文件名将被存储。

@H_502_0@您可以使用以下命令来检查库或程序的动态部分的内容：

@H_502_0@$ objdump -p program

@H_502_0@这在实践中如何使用？ 那么，大多数（所有？）Linux发行版使用以下方案，与系统库（采取libfoo.so ）：

@H_502_0@该库被安装为/usr/lib/libfoo.so.1.2或任何版本。

@H_502_0@是指向/usr/lib/libfoo.so.1和/usr/lib/libfoo.so库的符号链接。

@H_502_0@库的SONAME是libfoo.so.1 。

@H_502_0@路径/usr/lib被设置为动态库路径。

@H_502_0@这样，当你链接到-lfoo它会找到符号链接libfoo.so ，但会将SONAME记录为libfoo.so.1 。 而当程序运行时，会发现另一个符号链接并加载库。

@H_502_0@这个技巧是用来安装一个ABI兼容的，改进的libfoo.so.1.3和一个ABI不兼容的更新的libfoo.so.2.1 ，而旧的程序将加载旧的库，而新的编译将使用新的库。

@H_502_0@另请注意，环境变量LD_PRELOAD ， LD_LIBRARY_PATH等影响运行时行为。 有关更多详细信息，您可以阅读man ld.so