【问题标题】:how to make sure that boost is successfully installed?如何确保成功安装了boost?
【发布时间】:2012-05-21 14:33:41
【问题描述】:

我正在尝试安装一个明确声称需要安装 boost 的 linux 工具。(http://www.statmt.org/moses/?n=Development.GetStarted)

我已经下载了boost1.42的源代码(放在/usr/local/boost1.42)进行编译。虽然编译过程产生了很多错误和警告(正常吗?boost官网说应该不会有其他错误,除了IO错误。),最后我得到了/usr中的/stage/lib和/boost /local/boost1.42 目录。现在我可以运行如下示例:

 #include <boost/regex.hpp>
#include <iostream>
#include <string>

int main()
{
    std::string line;
    boost::regex pat( "^Subject: (Re: |Aw: )*(.*)" );

    while (std::cin)
    {
        std::getline(std::cin, line);
        boost::smatch matches;
        if (boost::regex_match(line, matches, pat))
            std::cout << matches[2] << std::endl;
    }
}

 $ c++ -I /usr/local/boost_1_42_0 example.cpp -o example -L~/usr/local/boost_1_42_0/stage/lib/ -lboost_regex

这实际上会发出一个可执行文件“example”,没有编译警告和正确的行为。 但是当我想查看它的链接细节时:

$ldd -v example

结果相当混乱:

    linux-vdso.so.1 =>  (0x00007fffb4b9c000)
    libboost_regex.so.1.42.0 => not found
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003f79600000)
    libm.so.6 => /lib64/libm.so.6 (0x0000003f72e00000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003f78e00000)
    libc.so.6 => /lib64/libc.so.6 (0x0000003f72200000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003f72a00000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003f71e00000)

    Version information:
    ./example:
            libgcc_s.so.1 (GCC_3.0) => /lib64/libgcc_s.so.1
            libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0
            libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
            libstdc++.so.6 (CXXABI_1.3) => /usr/lib64/libstdc++.so.6
            libstdc++.so.6 (GLIBCXX_3.4) => /usr/lib64/libstdc++.so.6
    /usr/lib64/libstdc++.so.6:
            libm.so.6 (GLIBC_2.2.5) => /lib64/libm.so.6
            ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
            libgcc_s.so.1 (GCC_4.2.0) => /lib64/libgcc_s.so.1
            libgcc_s.so.1 (GCC_3.3) => /lib64/libgcc_s.so.1
            libgcc_s.so.1 (GCC_3.0) => /lib64/libgcc_s.so.1
            libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
            libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6
            libc.so.6 (GLIBC_2.3.2) => /lib64/libc.so.6
            libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
    /lib64/libm.so.6:
            libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
            libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
    /lib64/libgcc_s.so.1:
            libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
            libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
    /lib64/libc.so.6:
            ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
            ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
    /lib64/libpthread.so.0:
            ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
            ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /lib64/ld-linux-x86-64.so.2
            ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
            libc.so.6 (GLIBC_2.3.2) => /lib64/libc.so.6
            libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
            libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6

似乎链接器在 /usr/local/boost1.42/stage/lib/libboost_regex.a 中没有找到 libboost_regex.a(参见 ldd 日志:libboost_regex.so.1.42.0 => 未找到) .

那么它真正想要加载哪个库?为什么“未找到”会产生正确的可执行文件?

如果我想确保 boost 安装成功,我是否必须将 /usr/local/boost1.42 和 /usr/local/boost1.42/stage/lib 导出到任何地方,以便其他程序可以知道它的位置吗?

谢谢! 洪斌

【问题讨论】:

  • 一些 Linux 发行版正在打包。你可以安装相关的包。
  • 您选择 Boost 1.42 有什么原因吗?到现在已经有几年了(当前版本是 1.49)。
  • @JerryCoffin 实际上我尝试了 1.49,遇到了同样的问题,所以我选择了一个随机的..
  • 很公平——但由于这没有帮助,我想我会回到 1.49。

标签: c++ linux boost centos


【解决方案1】:

要在非标准位置(未在 ld.so.conf 中指定)安装 boost 并使用它:

  1. 使用--prefix--libdir 选项配置提升:

    $ ./bootstrap.sh --prefix=${PREFIX} --libdir=${PREFIX}/lib64
    
  2. 构建并安装 boost 设置 rpath 为与--libdir 相同的值,例如${PREFIX}/lib64:

    $ ./b2 -d+2 --layout=system variant=release link=shared threading=multi runtime-link=shared linkflags="-Wl,-rpath,${PREFIX}/lib64"
    
    $ sudo ./b2 -d+2 --layout=system variant=release link=shared threading=multi runtime-link=shared linkflags="-Wl,-rpath,${PREFIX}/lib64" install
    
  3. 编译你的应用程序指定boost包含目录:

    $ g++ -c -I${PREFIX}/include ...
    
  4. 链接你的应用程序指定 boost lib 位置。还将 rpath 嵌入到二进制文件中,这样应用程序就可以找到 boost 库而不必摆弄LD_LIBRARY_PATH

    $ g++ -L${PREFIX}/lib64 -Wl,-rpath,${PREFIX}/lib64 ...
    

在上面设置 PREFIX 以提升安装位置,例如export PREFIX=/usr/local/my_boost.

【讨论】:

  • 对我来说这很有效:./b2 hardcode-dll-paths=true dll-path=${PREFIX}/lib64
  • @HiB 不错,不知道他们的构建系统是否可行。
【解决方案2】:

是的,您需要告诉动态链接器共享对象(.so 文件,而不是 .a 文件)的位置。

这可以通过将LD_LIBRARY_PATH 设置为正确的路径(并将其导出)或编辑/etc/ld.so.conf(或其他一些设置文件,具体取决于发行版)来完成。

(另一种选择是在链接可执行文件时使用rpath选项,但环境设置对于开发来说更加灵活。)

【讨论】:

  • 谢谢,垫子。实际上 .so 和 .a 都在 /usr/local/boost1.42/stage/lib 中。您能否进一步解释为什么即使 libboost_regex.so.1.42.0 => not found 也能正确编译该示例?
  • 你告诉编译器(和链接器)在哪里可以找到这些文件(-L)。你没有告诉运行时链接器。
  • 我会说-Wl,-rpath 是最好的选择。环境变量是一个糟糕的选择,因为如果未设置 LD_LIBRARY_PATH,应用程序将无法启动。
  • rpath 如果您想分发 exe,这不是一个好的选择 - 这将取决于在那个奇怪的路径中拥有 boost 库。让动态运行时链接器定位文件比硬编码开发框的路径要好得多。 (除非你也运送这些库。)
  • 如果分发可执行文件并使用自定义库,它们也必须分发。
猜你喜欢
  • 2011-07-21
  • 1970-01-01
  • 2018-12-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-04-28
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多