首页 文章

如何从g COLLECT_LTO_WRAPPER获取生成生成的.so文件的信息？

提问于
浏览 次
1

当我从命令行使用g编译一个c程序然后执行 ldd a.out ldd is 能够找到libstdc .a（libstdc .so.6）

当我构建一个c ruby扩展 ldd myext.so cannot 找到libstdc .a（libstdc .so.6），并且 require 'myext' 无法加载时，抱怨无法找到libstdc .

如果我运行g -v，我会看到以下输出：

COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/big_long_path....
Target: powerpc-ibm-aix7.1.0.0
Configured with: ../gcc-4.8.2/configure .....
Thread model: aix
gcc version 4.8.2 (GCC)

现在，如果我将 LIBPATH 设置为包含该big_long_path

export LIBPATH=/big_long_path....:$LIBPATH

ldd myext.so

is 能够找到libstdc和我的 require 'myext' 工作（返回true）

这可能没问题，但我宁愿不要让用户吝啬他们的LIBPATH . 有什么东西可以添加到我的Makefile中，允许生成的myext.so在我运行g -v时看到的COLLECT_LTO_WRAPPER行中看到的big_long_path指向的位置找到libstdc（和libgcc）吗？

更新

下面接受的答案中的第一个链接确实帮助我理解了发生了什么，并且我能够通过将-blibpath：big_long_path：/ usr：/ usr / lib添加到Makefile中的LDFLAGS来让ldd不抱怨libstdc .

但出于某种原因，当ruby试图加载ext时，它仍然失败了 . 这让我觉得红宝石在某种程度上调整了LIBPATH . 最后，我的解决方案是在ruby安装的lib目录中放置一个符号链接到libstdc和libgcc_s . 想法是ruby必须要搜索扩展共享对象，所以我想我会利用这个并将这两个库放在ruby必须搜索的路径中 . 我唯一想知道的是，我是否应该只复制libstdc和libgcc_s而不是象征性地链接它们？

c++ makefile g++ aix ruby-c-extension

2 回答

  • 1
    回复于
  • 0

    不要让加载器搜索库，使用选项 -Wl,-bipath ;用 dump -X32_64 -H 检查结果;你应该看到这样的东西：

    INDEX  PATH                          BASE                MEMBER              
0      /usr/local/lib:/usr/lib:/lib                                          
1      /usr/local/lib                libapr-1.so.0                           
2      /usr/local/lib                libaprutil-1.so.0                       
3      /usr/local/lib                libcrypto.so.1.0.1f                     
4      /usr/local/lib                libexpat.so.1                           
5      /usr/local/lib                libgcc_s.a          shr.o               
6      /usr/local/lib                libiconv.so.2                           
7      /usr/local/lib                libssl.so.1.0.1f                        
8      /usr/local/lib                libcpotlas.so.1                         
9      /usr/lib                      librtl.a            shr.o               
10     /usr/lib                      libc.a              shr.o               
11                                   .

    另外我不得不说使用C for plugin是一个非常糟糕的主意，特别是在像AIX这样的奇异系统中

    回复于

相关问题