木牛的博客

多进程引用动态链接库中的全局变量问题现象描述：前提：存在一个动态库libvlan.so，存在一个应用console。做法：在console中调用libvlan.so中的两个APIs，分别是设置和获取动态库中一个全局变量的值。结果：在console中的操作没有问题，设置和获取都正常；但在动态库中打印该全局变量，其值并没有改变。结论：动态库中的全局变量，在被其他进程使用时，会拷贝一份，所以多个进程使用同一个动态库中的全局变量也不会相互影响。也不会改变动态库中该变量的值。类似于fork的COW技术。网络资料：现有

之前在linux下做过一个测试：写一个so，该so中有一个全局变量。so中的代码在运行时会修改该全局变量的值。然后，有多个程序都需要该so，而且这些应用程序都启动了。此时，很显然so只被加载了一份，那么，当这么多程序在运行调用该so时，该so中的全局变量的值会被覆盖来覆盖去么？答案是不会。这是测试的答案。现在知道原理了，尽管这是windows via C/C++中解释的windows的做法，但是我想linux也是这么类似处理的。windows 使用memory map来加载exe和dll。当一个exe/dl

最近打算把linux下的一个c++程序以插件的形式实现，即主程序加载so功能模块的方式，在这个过程中，遇到了一个全局符号覆盖的问题，查了一些资料有了初步的了解，这里记录一下。遇到的问题是：程序以dlopen方式加载so文件时，如果so文件和程序存在同名的全局变量，主程序的全局变量会so文件中的全局变量覆盖。由此，引出的问题如下1、同名全局变量覆盖与dlopen的打开方式是否有关？2、与主程序和so文件的编译选项是否有关？3、以静态库.a直接连接是否也存在这个现象？4、以动态库.so直接链接是否也存在这个问题

在linux环境下编程，我们如果想要使用第三方的库，基本上有以下几种方式：这4种方式：这里我们先说结论：测试的思路就是对比，对比源码、静态库、动态库显性调用、动态库隐性调用，这4种方式的内存占比情况。我们实现一种简单的场景，编写一个 加、减、乘、除、打印等功能的 计算库，主程序中调用该库，计算库源码如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

hdfs增加了一个native方法，打成了libhadoop.so这个动态库。需要分发到线上的各个Datanode上以便升级。在灰度分发到datanode时遇到了可复现的问题，即datanode进程肯定会core dump。分析core dump时产生的hs_err_pid.log文件后，发现最后的执行现场都是在执行native方法。怀疑和替换.so文件有关。Google了一下，关键词：“如何动态替换.so文件”。确实能够解决问题，即我之前用的是cp -rf这种粗鲁的覆盖文件的手段，优雅的方法是mv+cp的

so文件：动态库a文件： 静态库exe文件：可执行程序（linux下以文件属性来标示是否是可执行文件，与后缀名无关）经过自己写的一些测试程序，大致了解了下gcc中链接顺序问题，总结出以下几点：1，动态库中可以包含另一个静态库，通过参数 -lxxx 把静态库libxxx.a加入so文件中，这样so文件中 就包含了libxxx.a的所有实现。当然，如果不包含libxxx.a也没有问题，这样生成的so会小一点。 如果不包含libxxx.a，最终使用这个so的可执行文件，在其生成时必须加入 -l...

GCC 编译使用动态链接库和静态链接库1 库的分类根据链接时期的不同，库又有静态库和动态库之分。静态库是在链接阶段被链接的（好像是废话，但事实就是这样），所以生成的可执行文件就不受库的影响了，即使库被删除了，程序依然可以成功运行。有别于静态库，动态库的链接是在程序执行的时候被链接的。所以，即使程序编译完，库仍须保留在系统上，以供程序运行时调用。（TODO：链接动态库时链接阶段到底做了什么）2 静态库和动态库的比较链接静态库其实从某种意义上来说也是一种粘贴复制，只不过它操作的对象.

1. 库的介绍库是写好的现有的，成熟的，可以复用的代码。现实中每个程序都要依赖很多基础的底层库，不可能每个人的代码都从零开始，因此库的存在意义非同寻常。本质上来说库是一种可执行代码的二进制形式，可以被操作系统载入内存执行。库有两种：静态库（.a、.lib）和动态库（.so、.dll）。 windows上对应的是.lib .dll linux上对应的是.a .so在这里先介绍下Linux下的gcc编译的几个选项g++ -c hellospeak.cpp会将hellospeak.cpp

针对同一动态组件的不同版本链接和加载。一、概念 DLL HELL字面意思是DLL"灾难"，是由于com组件（动态库）升级引起的程序不能运行的情况。 原因 有三种可能的原因导致了DLL Hell的发生： 一是由使用旧版本的DLL替代原来一个新版本的DLL而引起的。这个原因最普遍，是Windows 9X用户通常遇到的DLL错误之一。 二是由新版DLL中的函数无意发生改变而引起。...

在 linux 下编写动态链接库程序，需要注意dll 之间的符号冲突。当我们链接库需要提供给很多方集成使用，需要面对复杂的集成环境，其中一个大问题就是与第三方集成环境的符号冲突。这些冲突有些不是通过严格控制名字空间解决的，比如当我们使用了一些开源库，我们不清楚第三方集成环境有没有这些库，即使有是不是版本匹配，我们也不想对第三方集成环境提太多要求，这会增加集成成本。在这种情况下，我们会将这些开源库静态链接到我们的动态链接库中，仅提供一个 so 文件。但是这样做不足以避免符号冲突。linux 下的动.

linux默认对库的连接是使用动态库在应用程序需要连接外部库的情况下，linux默认对库的连接是使用动态库，在找不到动态库的情况下再选择静态库。使用方式为：gcc test.cpp -L. -ltestlib1如果当前目录有两个库libtestlib.so libtestlib.a 则肯定是连接libtestlib.so。如果要指定为连接静态库则使用：gcc test.cpp -L. -static -ltestlib1使用静态库进行连接。对动态库与静态库混合连接 -Wl当对

1. 问题重现模型为了重现问题并去掉无关干扰细节，我们将构建一个最简单的可执行模块和依赖模块的关系链，程序依赖模型如下：1.1 解释（1）有一个名为RTSP的第三方库提供了公共接口RTSP_OPEN，RTSP可以编译为静态库libRTSP_STATIC.a也可以编译为动态库libRTSP_SHARED.so。（2）基于RTSP库封装了一个名为STREAM的库，该库以动态库libSTREAM.so的形式提供使用。STREAM库提供了1个名为STREAM_OPEN的接口，该接口在内部使用RTSP库提

万事皆有缘由，还是先从我遇到的这个问题说起～～～问：有一个主执行程序main，其中实现了函数foo()，同时调用动态库liba.so中的函数bar()，而动态库liba.so中也实现了foo()函数，那么在执行的时候如果在bar()中调用foo()会调用到哪一个？在main()中调用呢？ 直接给答案：如果是在Linux上，liba.so中的foo()函数是一个导出的(extern)”可见”函数，那么调用会落入主程序里，这对于liba.so的作者来说实在是个灾难，自己辛辛苦苦的工作竟然被自己人视而不见，偏偏误

Linux下.ko, .o, .so, .a, .la文件 分类：Linux 系列2011-12-12 23:302669人阅读评论(0)收藏举报linuxgccmakefilelibrarywindowspathLinux下文件的类型是不依赖于其后缀名的，但一般来讲：.ko 是Linux 2.6内核使用的动态连接文件的后缀名，也就是模块文件，用来在Linux系统启动时加载内核模块.o 是目标文件,相当于windows中的.obj文件...

曾经在一次写程序的时候，全局使用一个日志对象，所有的日志信息都由此日志对象写入文件。但是发现在动态链接库里，无法存取到该全局对象，后经查找资料。发现，动态链接库是否能存取主程序的全局变量，主程序是否能存取动态链接库里定义的全局变量都是可以通过链接指令改变此行为。主程序存取动态链接库里的全局变量例如动态库里定义全局变量int i, 在主程序里申明extern int i。 则，主程序存取的就是动态库里定义的i。在所有的UNIX平台上这是默认的行为（注意：实际定义i的 模块的点o文件，必须同时链接到动态库和

共享库与静态成员吴 光远 和 孟 先涛2010 年 10 月 21 日发布Linux 支持的共享程序库（lib*.so）技术不仅能够有效利用系统资源，而且还对程序设计带来了很大的便利性、通用性等，因此被各种级别的应用系统广泛采用。 动态链接的共享库是在加载应用程序时被加载的，而且它与应用程序是在运行时绑定的：通过动态链接器，将动态共享库映射进应用程序的可执行内存中（动态链接）；在启动应用程序时，动态装载器将所需的共享目标库映射到应用程序的内存（动态装载）。在通常情况下，共享库都是通过使用附加选

问题描述回归正题，前段时间项目开发中，实现了一个动态库，封装了一些方法。然后基于这个动态库，实现了一个应用程序。应用程序中含有全局变量A，动态库中也含有全局变量A，当我调用动态库中函数后，发现应用程序的A发生了变化！！！O，My God！对于我这种还没在Linux下做过开发的人来说，一头雾水。。。。。。 于是我尝试着，将A中的变量名称改为B，这样问题也就没有了~~~原因应用程序进行链接的时候，动态库中全局变量定义，将会被应用程序中同名的全局变量所覆盖。这样也就造成了，在动态库中修改A..

众所周知，Linux动态库的默认搜索路径是/lib和/usr/lib。动态库被创建后，一般都复制到这两个目录中。当程序执行时需要某动态库，并且该动态库还未加载到内存中，则系统会自动到这两个默认搜索路径中去查找相应的动态库文件，然后加载该文件到内存中，这样程序就可以使用该动态库中的函数，以及该动态库的其它资源了。在Linux中，动态库的搜索路径除了默认的搜索路径外，还可以通过以下三种方法来指定。方法一：在配置文件/etc/ld.so.conf中指定动态库搜索路径。可以通过编辑配置文件/etc/ld.

今天blog不好用了.借用寶地一下.*深入分析Windows和Linux动态库应用异同***摘要：动态链接库技术实现和设计程序常用的技术，在Windows和Linux系统中都有动态库的概念，采用动态库可以有效的减少程序大小，节省空间，提高效率，增加程序的可扩展性，便于模块化管理。但不同操作系统的动态库由于格式不同，在需要不同操作系统调用时需要进行动态库程序移植。本文分析和比较...