精华内容
下载资源
问答
  • 最近项目用到了opencv,在测试环境编译后生成了so文件,在测试环境运行正常后准备在预发环境进行上线前的测试 但是System.loadLibrary(Core.NATIVE_LIBRARY_NAME)一直加载不...安装对应的依赖so文件后再次部署,运行

    最近项目用到了opencv,在测试环境编译后生成了so文件,在测试环境运行正常后准备在预发环境进行上线前的测试

    但是System.loadLibrary(Core.NATIVE_LIBRARY_NAME)一直加载不成功,也没有报错

    更改捕获Exception为Throwable,发现libopencv_java330.so的某个依赖文件没找到或者不存在

    安装对应的依赖so文件后再次部署,运行后又报了另一个so文件不存在,这总不能部署一次报一次错安装对应的so文件吧

    这个时候就需要查看该so文件依赖哪些so文件,并且哪些是没有的,从而一次安装

    此时可通过如下命令

    ldd libopencv_java330.so

    发下有的依赖是not found,这就需要去安装全后才可以正常使用


    以下是依赖都存在的结果


    展开全文
  • (1)开源的class_loader生成so文件,作为插件生成、加载等的基础; (2)插件基类,包括标签生成器基类、传感器数据采集基类,依赖class_loader,目的是为具体的插件提供头文件; (3)标签生成器插件,用户自己...

    这一段一直在整插件管理框架的事情,整个框架分成几层:

    (1)开源的class_loader生成so文件,作为插件生成、加载等的基础;

    (2)插件基类,包括标签生成器基类、传感器数据采集基类,依赖class_loader,目的是为具体的插件提供头文件;

    (3)标签生成器插件,用户自己实现genLabel函数,通过用户逻辑来控制输出的标签的内容、长度等,这个插件依赖于class_loader和插件基类;

    (4)传感器数据采集插件,也是以class_loader为基础,同时依赖标签生成器和插件基类;

    (5)插件管理框架,将所有的插件管理起来,实际上直接依赖于class_loader和插件基类。

    现在按照上述层次关系,依次编译安装。但在使用过程中,例如对于插件管理框架,用户想着我只是用你的插件管理框架,我引入该框架的.so文件即可,至于你依赖谁,我并不关心,我也不应该知道,我更不应该引入这些so文件。这是因为在默认情况下,库依赖项是传递的。当目标A 链接到目标B 时,链接到A 的库也会出现B 的链接线上。

    上述几个工程都在同一个目录下,属于平级关系,如下图所示。

    我们在编译完插件管理框架后,使用ldd查看链接关系,发现所有库都是链接上的。

    对应的cmakelists文件如下:

    cmake_minimum_required(VERSION 3.4.2)
    
    project(pluginManager CXX)
    
    # Default to C++14
    if(NOT CMAKE_CXX_STANDARD)
      set(CMAKE_CXX_STANDARD 14)
    endif()
    if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang")
      add_compile_options(-Wall -Wextra -Wpedantic -pthread -lboost_filesystem)
    endif()
    
    include(../micros.cmake)
    set(LINK_DIR ./lib ) # can not be obsolute path
    set(CONSOLE_DIR /lib/x86_64-linux-gnu/)
    set(POCO_DIR /usr/lib/x86_64-linux-gnu/)
    set(CLASS_LOADER_LIB /opt/micros/1.0.1/third-party/class_loader/lib)
    message("aaaaaaaaaa" ${CMAKE_INSTALL_PREFIX})
    set(${PROJECT_NAME}_SRCS src/pluginManager.cpp)
    set(${PROJECT_NAME}_HDRS include/micros_pluginmanager/pluginManager.h)
    
    include_directories( ./include /usr/include)
    
    include_directories(/opt/micros/1.0.1/include)
    include_directories(${CMAKE_INSTALL_PREFIX}/third-party/class_loader/include)
    link_directories(${CMAKE_INSTALL_PREFIX}/lib 
    #${CMAKE_INSTALL_PREFIX}/third-party/class_loader/lib
    #${CLASS_LOADER_LIB}
     ${CMAKE_TMP_OUTPUT_SO_PATH}
     )
    SET(LIBRARY_OUTPUT_PATH ${CMAKE_TMP_OUTPUT_SO_PATH})
    
    link_directories(${LINK_DIR}
                     ${CONSOLE_DIR} 
                     ${POCO_DIR} 
                    /opt/micros/1.0.1/lib/plugins
                     ${CLASS_LOADER_LIB})
    
    #插件基类对应的so文件
    add_library(label_sensor.0.1.0 SHARED IMPORTED)
    set_property(TARGET label_sensor.0.1.0 PROPERTY IMPORTED_LOCATION "/opt/micros/1.0.1/lib/plugins/liblabel_sensor.0.1.0.so")
    #class_loader对应的so文件
    add_library(libmicros_scene_classloader.0.1.0 SHARED IMPORTED)
    set_property(TARGET libmicros_scene_classloader.0.1.0 PROPERTY IMPORTED_LOCATION "/opt/micros/1.0.1/third-party/class_loader/lib/libmicros_scene_classloader.0.1.0.so")
    
    
    add_library(micros_scene_pluginmanager.0.1.0 SHARED ${${PROJECT_NAME}_SRCS} ${${PROJECT_NAME}_HDRS})
    
    target_link_libraries(micros_scene_pluginmanager.0.1.0  optimized
      label_sensor.0.1.0
      micros_scene_classloader.0.1.0
      
    ) 
    #安装so文件到/opt/xxx/lib/目录下
    install(TARGETS micros_scene_pluginmanager.0.1.0 LIBRARY DESTINATION lib/)
    install(DIRECTORY include/  DESTINATION include/) 

    当我们安装后,也就是执行sudo make install之后,发现插件基类库和class_loader库并没有链接上去:

    查了不少原因,尝试了不少方法还是不行。最后,我们思考一下,安装前后的区别是什么?是搜索路径:

    问题

    如果ldd命令没有找到对应的共享库文件和其具体位置?

    可能是两种情况引起的:

    1)共享库没有安装在该系统中;

    2)共享库保存在/etc/ld.so.conf文件列出的搜索路径之外的位置。

    通常情况下,许多开源代码的程序或函数库都会默认将在即安装到/usr/local目录下的相应位置(如:/usr/local/bin 或 /usr/local/lib)以便于系统自身的程序或函数库相区别。而许多linux系统的/ect/ld.so.conf 文件中默认又不包含 /usr/local/lib 。因此出现安装了共享库,但是却无法找到共享库的情况。

    解决办法:
    检查/etc/ld.so.conf文件,如果其中缺少自己编译的被依赖的库的目录,就添加进去;
    注意:在修改了/etc/ld.so.conf 文件或者在系统中安装了新的函数库之后,需要运行命令 ldconfig ,该命令用来刷新系统的共享库缓存,即 /etc/ld.so.cache 文件。为了减少共享库系统的库搜索时间,共享库系统维护了一个共享库so名称的缓存文件 /etc/ld.so.cache 。 因此,在安装新的共享库之后,一定要运行 ldconfig刷新该缓存。

    我们添加插件基类库和class_loader库文件所在路径到/etc/ld.so.conf文件中,如下图所示:

    然后执行sudo /sbin/ldconfig使上述修改生效。

    重新安装插件管理框架库文件,然后ldd查看:

    至此,链接库找不到的问题解决。

    虽然上面的问题解决了,但是给我留下一个更大的疑惑

    疑惑:

    为什么在生成so文件的地方使用ldd查看依赖关系的时候,这些库是能找到的呢?如果说当前路径是默认添加到搜索路径的,我可以理解,但是,pluginmanager.so依赖于label_sensor.so和class_loader.so,但它们俩并不在当前目录下!!!

    1. 测试将make生成so文件移动位置到其他地方,看能否链接成功

    我可以将so文件移动到home/ok/下的任意位置,ldd查看都是能链接上的!

    移动到/home/ok/code/下

    移动到/home/ok/下,该文件仍然属于ok用户。

    将so文件移动到/home/下

    将so文件移动到/var下:

    移动到/opt/micros/1.0.1/lib/下:

    链接没问题,这就意味着make出来的so文件,是记录了它所依赖的其他so文件的路径信息的。

    2. 测试将make install后的so文件移动到其他地方(已经将搜索路径从/etc/ld.so.conf文件中删除)

    我们将它移动到/var目录下:

    我们把安装后的so文件复制到/home/ok/下,然后查看(用户是root):

    我们发现,将安装后的so文件移动到任何一个位置,都无法找到依赖包。

    上述两个文件的区别仅仅是文件的属主,一个是ok,一个是root。

    那么,使用make生成so文件时,依赖库的路径信息到底有么有被放到目标so中呢?如果放进去了,这个好理解,该文件可以随便移动,但是存在弊端:如果你依赖的库文件移动位置了,那就肯定找不到了。我们验证一下,把label_sensor.so从lib/plugins下移动到third-party/class_loader/lib下。(这俩路径目前都不在系统的/etc/ld.so.conf文件中)

    再挪回来:

    我们发现,labe_sensor.so虽然更换了路径,但是仍然能找到,这说明make生成so文件时,依赖库的路径并没有被放到so文件中。

    那么我们思考一下,是不是每一个用户都有一个搜索路径呢?

    如果每个用户都有一个搜索路径,那我把label_sensor.so移动到一个其他位置,是否还有效呢?

    我们将label_sensor.so移动到/opt/micros/下,然后查看:

    我们发现,找不到label_sensor.so,这也就说明(1)so文件中不记录所依赖的其他so文件的路径,只记录so文件名;(2)有可能,每个用户都有一个搜索路径,并且在执行CMakelists.txt对应的make的时候,会把link_directories和add_library添加的依赖路径添加到执行make命令的用户的搜索路径下;(3)有可能每一个so文件里面都包含了一个搜索路径,就是cmakelists.txt中的link_directories和add_library以及target_link_libraries引入的路径,当使用so或者ldd该so文件的时候,会根据so文件里面包含的路径去查找,但这样的话,即使切换用户,应该也能找到!所以这个成立的可能性很小!!!

    3. 使用sudo make来编译so文件

    生成so文件:

    然后安装该文件:

    发现不行,仍然找不到路径。

    我们使用sudo cmake ..; sudo make 再来一遍:

    sudo make install:

    仍然不行,现在我们将sudo cmake ..和sudo make得到的so文件复制到/opt/micros/1.0.1/lib/下:

    发现可以了,这说明是sudo make install破坏了原来的依赖关系!!!

    这说明前面的第二条推论也可能是错误的!!!也就是并不是在cmake ..和make的时候,会将相应的路径添加到用户的搜索路径中?但是如果这样的话,怎么解释make出来的so文件随便移动,其都能找到依赖的so文件,并且其依赖的so文件移动到某些路径下(生成目标so时的link_dictories和add_library以及target_link_libraries指定的路径下)仍然能找到呢?

    是不是生成目标so文件时,附带了对应该so的cmakelists中的link_dictories和add_library以及target_link_libraries的路径呢?也就是前面的推论(3)可能是成立的!但是sudo make install破坏了这种关系。

    我们查看以下make和make install后的文件大小的区别:

    上面的是复制过来的,下面的是安装过来的,大小一致,唯一的区别是make得到的有可执行权限。

    为什么make出来的so文件的库依赖是没有问题的,而make install出来的库文件需要添加依赖库的路径到/etc/ld.so.conf文件中呢?

    限于篇幅问题,我在下一个blog中继续探索!

    有一点需要说明,添加到/etc/ld.so.conf文件中的搜索路径必须是so文件的直接父路径,不能是祖先路径。貌似ldd不会便利某路径下的子目录。

    展开全文
  • 今天小编就为大家分享一篇关于linux查看so或可执行程序的依赖库,小编觉得内容挺不错的,现在分享给大家,具有很好的参考价值,需要的朋友一起跟随小编来看看吧
  • 树莓派raspbian环境下编译的so文件,支持sigar-1.6。 注:不同版本sigar需要使用对应版本的so库文件。
  • Linux查看可执行文件依赖

    千次阅读 2020-04-15 10:15:04
    Linux查看文件依赖库使用 ldd 命令查看依赖库曲线方式查看可执行文件依赖情况使用交叉编译工具链查看依赖情况 使用 ldd 命令查看依赖库 在Linux系统中,一般使用ldd指令查看某个可执行文件依赖的动态库,命令如下 ...

    使用 ldd 命令查看依赖库

    在Linux系统中,一般使用ldd指令查看某个可执行文件所依赖的动态库,命令如下

    ldd filename
    

    曲线方式查看可执行文件依赖情况

    在运行环境下,启动可执行文件,通过ps指令获取其pid值(例如pid=298),然后输入如下指令获取其依赖情况。

    cat /proc/298/maps
    

    使用交叉编译工具链查看依赖情况

    1. 使用 xxx-linux-objdump 命令查看文件依赖情况
    xxx-linux-objdump -x "filename" | grep "NEEDED"
    
    1. 使用 xxx-linux-readelf 命令查看文件依赖情况
    xxx-linux-readelf -a "filename" | grep "Shared"
    

    注意:需要把可执行文件拷贝至编译环境下输入对应指令查看

    展开全文
  • linux查看动态链接库so文件依赖的相关组件  我们很多c程序在windows下是以dll形式展现的,在linux则是以so 形式展现的。  windows一般不会因为编译dll文件的编译器版本不同而出先dll文件不能执行。  ...

    linux下查看动态链接库so文件的依赖的相关组件

      我们很多c程序在windows下是以dll形式展现的,在linux则是以so 形式展现的。

      windows一般不会因为编译dll文件的编译器版本不同而出先dll文件不能执行。

      但是linux下,不同版本内核的linux下编译的c程序,在其他版本的linux下就容易出现无法执行的问题。主要可能是支持程序的内核相对于编译时的内核较高或者版本相对于编译时的内核较低。

      那我们如何看别人给我们提供的动态链接库文件(so后缀的)是否能在当前linux系统下可用呢。首先我们就要看他依赖的相关文件是否存在,查看命令如下:ldd file.so

    假如我想看jnative的动态链接库在某个版本的linux下是否被支持,先切换到文件所在目录,然后写下如下命令:

     ldd libJNativeCpp.so

     如果正常,显示如下:

             libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0069c000)
            libm.so.6 => /lib/tls/libm.so.6 (0x00111000)
            libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00562000)
            libc.so.6 => /lib/tls/libc.so.6 (0x00134000)
            /lib/ld-linux.so.2 (0x0097b000)
     如果不正常可能显示如下:

    ./libJNativeCpp.so: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by ./JNativeCpp.so)
            libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0047e000)
            libm.so.6 => /lib/tls/libm.so.6 (0x00111000)
            libc.so.6 => /lib/tls/libc.so.6 (0x0056e000)
            libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00c3d000)
            /lib/ld-linux.so.2 (0x0097b000)

    这里是那个有名的jni第三方类库的默认的lib,上边的错误信息显示就是说我们的libJNativeCpp.so是在2.4内核下编译的,当前内核版本不支持。经过查看,我当前的linux版本的内核是2.6高于libJnativeCpp.so编译时的内核。

    展开全文
  • 我们很多c程序在windows下是以dll形式展现的,在Linux则是以so 形式展现的。  windows一般不会因为编译dll文件的编译器版本不同而出先dll文件不能执行。  但是linux下,不同版本内核的linux下编译的c程序,在...
  • Linux查看.so文件中函数

    万次阅读 2014-12-04 09:43:44
    windows 中查看进程依赖哪个dll,使用depends,linux使用ldd命令。 查看dll中有哪些导出函数windows使用dumpbin,linux使用objdump查看so中有哪些函数。 eg: objdump -tT libX.so 查看dll中符号的地址使用nm。 ...
  • 将程序依赖的所有库文件拷贝出来 ldd helloworld | awk '{print $3}' | xargs -i cp -L {} /home/zz/lib helloworld是可执行程序名称,/home/zz/lib是拷贝依赖库的目标文件夹 如果需要有选择的拷贝,则可以加入...
  • 我们很多c程序在windows下是以dll形式展现的,在linux则是以so 形式展现的。  windows一般不会因为编译...  那我们如何看别人给我们提供的动态链接库文件so后缀的)是否能在当前linux系统下可用
  • 1,需要的头文件和cpp 文件 ==========test.h=========== #ifdef __cplusplus // 注意,这里是双下划线!!! extern "C" { #endif class Test{ //有类写类,没有就不写了 public: int hello(int i); }; ...
  • Linux动态链接(3)so文件映射地址

    千次阅读 2016-08-03 21:22:13
    so文件一般在程序刚启动的时候由动态连接器映射入可执行程序的地址空间,也可以通过dl库中的dlopen来映射入可执行程序的地址空间中,它的底层实现都是通过mmap来实现,这个没有什么好说的。通常来说,我们自己使用的...
  • linux 显式链接so

    千次阅读 2018-06-08 10:49:56
    linux加载程序变成进程的过程 fork进程, 在内核创建进程相关内核项, 加载进程可执行文件 查找依赖so库, 加载映射虚拟地址 初始化程序变量 动态库依赖越多, 进程启动就越慢, 并且发布程序的时候, 这些...查看链...
  • linux查看文件依赖的库

    千次阅读 2014-02-13 18:44:38
    一般使用ldd命令查看文件依赖的库(.so) ldd file 工具还提供了另外2个命令可以使用 xx-linux-readelf -a "your binary" | grep "Shared" xx-linux-objdump -x "your binary" | grep "NEEDED" 曲线方式 ...
  • linux查看so依赖的库

    千次阅读 2017-01-01 20:36:38
    查看依赖的库: objdump -x xxoo.so | grep NEEDED #2. 查看缺失的库: ldd xxoo.so #如果某个依赖的库不存在,会输出类似 OOXX.so not found 字样。  其它参考: 1. ...
  • linux ldd 查看依赖的库文件

    千次阅读 2017-02-22 23:42:27
    [root@localhost testProgs]# ldd openRTSP linux-vdso.so.1 => (0x00007ffd48294000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003f77000000) libm.so.6 => /lib64/libm.so.6 (0x0000003f6c400000) li
  • Linux动态链接库 so文件的创建与使用

    千次阅读 2019-02-17 13:45:02
    Linux动态链接库 so文件的创建与使用
  • 我们很多c程序在windows下是以dll形式展现的,在linux则是以so 形式展现的。 windows一般不会因为编译dll文件的编译器版本不同而出先dll文件不能执行。 但是linux下,不同版本内核的linux下编译的c程序,在其他...
  • linux 调用动态库so文件

    万次阅读 2012-05-02 14:55:09
    可以事先对这些函数进行编译,然后将它们放置在一些特殊的目标代码文件中,这些目标代码文件就称为库。库文件中的函数可以通过连接程序与应用程序进行链接,这样就不必在每次开发程序时都对这些通用的函数进
  • Centos7 查看so依赖的库

    千次阅读 2019-10-22 15:41:07
    #1. 查看依赖的库: objdump -x xxoo.so | grep NEEDED#2. 查看缺失的库: ldd xxoo.so #如果某个依赖的库不存在,会输出类似 OOXX.so not found 字样。
  • Linux下可执行程序包括可执行程序exe和so, 两者文件都是ELF打头的。 objdump -x libxxxxx.so | grep NEEDED objdump -x 可执行程序名 | grep NEEDED 或 arm-hisiv300-linux-objdump -x 可执行程序 | grep NEEDED...
  • linux中链接脚本ld文件详解

    万次阅读 2015-05-05 20:59:32
    今天在看uboot引导Linux部分,发现要对链接脚本深入了解,才能知道各个目标文件的内存分布映像,下面是我看到的一些资料 0. Contents 1. 概论 2. 基本概念 3. 脚本格式 4. 简单例子 5. 简单脚本命令 6. 对...
  • linux .so文件详解

    万次阅读 2014-03-07 16:36:07
    linux文件的类型是不依赖于其后缀名的,但一般来讲: .o,是目标文件,相当于windows中的.obj文件 .so 为共享库,是shared object,用于动态连接的,和dll差不多 .a为静态库,是好多个.o合在一起,用于静态连接 .la为...
  • Linux下静态库_库的基本概念;...nm查看库中包含那些函数、ar生成静态库,查看库中包含那些.o文件、ldd查看程序依赖的.so文件;gcc/g++与库相关的参数-L,-l,-fPIC,-shared;静态库链接时搜索过程;
  • 预备知识及环境搭建 1、NDK(native development Kit)原生开发工具...2、Cygwin:是windows平台上模拟Linux运行环境的工具,即window平台上的linux环境工具,so文件需要在linux平台上编译运行。对应:arm linux平台
  • .o 就相当于Windows里的obj文件 ....so 是shared object,用于动态连接的,和dll差不多  .o文件是链接文件,.a是静态库文件,靠.o文件生成,作为一个库为外部程序提供函数,接口。 生成.o文件: gcc ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 92,919
精华内容 37,167
关键字:

linux依赖链查看so文件

linux 订阅