【问题标题】:"Hidden symbol `atexit' is referenced by DSO" when using libtool with gcov将 libtool 与 gcov 一起使用时,“DSO 引用了隐藏符号‘atexit’”
【发布时间】:2012-07-27 01:42:04
【问题描述】:

我有一个 C++ 项目,它使用 GNU Autotools 构建脚本,使用 libtool 进行链接。最近我添加了 gcov 的代码覆盖检测,通过确保

GCOV_CFLAGS="-fprofile-arcs -ftest-coverage"
GCOV_LDFLAGS="-fprofile-arcs -ftest-coverage"

..get 分别包含在我的CFLAGSLDFLAGS 中。在使用 g++-4.2(由 homebrew 安装)的 OS X 10.7.4 上,一切正常。

在使用 g++ 4.6.3 的 Ubuntu 12.04 上,libtool 无法链接我的一项测试:

/bin/bash ./libtool --tag=CXX   --mode=link g++ -Wall -Wextra -Werror -ansi -fprofile-arcs -ftest-coverage -g -O0 -fprofile-arcs -ftest-coverage -L/usr/local/lib -Wl,-rpath -Wl,/usr/local/lib   -o myproj/inttests/locale_test myproj/inttests/locale_test.o myproj/app/libapp.la -lboost_thread-mt -lboost_system-mt -pthread -llog4cplus  
libtool: link: g++ -Wall -Wextra -Werror -ansi -fprofile-arcs -ftest-coverage -g -O0 -fprofile-arcs -ftest-coverage -Wl,-rpath -Wl,/usr/local/lib -o myproj/inttests/.libs/locale_test myproj/inttests/locale_test.o -pthread  -L/usr/local/lib myproj/app/.libs/libapp.so -lboost_thread-mt -lboost_system-mt /usr/lib/liblog4cplus.so -pthread
/usr/bin/ld: myproj/inttests/.libs/locale_test: hidden symbol `atexit' in /usr/lib/x86_64-linux-gnu/libc_nonshared.a(atexit.oS) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[2]: *** [myproj/inttests/locale_test] Error 1

如何在 ubuntu/g++ 4.6 上修复我的构建?

【问题讨论】:

    标签: gcc ubuntu linker libtool gcov


    【解决方案1】:

    在谷歌搜索后,我看到了this thread,它建议在运行./configure 时将--coverage 添加到CXXFLAGS。事实上,虽然它不适用于那张海报,但它适用于我:

    ./configure CXXFLAGS="--coverage"
    

    但是,这个变量是为包安装程序保留的,而不是维护者(我)。问题简化为“如何将它正确地合并到构建中?”

    这就是不够

    GCOV_CFLAGS="-fprofile-arcs -ftest-coverage --coverage"
    GCOV_LDFLAGS="-fprofile-arcs -ftest-coverage"
    

    假设GCOV_CFLAGS 包含在有效的CXXFLAGS 中(未显示,但确实如此),看来此修复程序应该有效。没有。

    进一步挖掘,如果我们从命令行中删除CXXFLAGS="--coverage" 并将其放在configure.ac 某处,我们似乎至少应该获得一些牵引力。实际上,这也不起作用除非该行位于选择编译器的AC_PROG_CXX 调用之上。

    所以现在我们有了一点了解。当AC_PROG_CXX 看到--coverage 时,它正在改变一些东西,这很可能是GCOV_CFLAGS 中的展示位置不起作用的原因:为时已晚。

    仔细查看日志,似乎秘诀是在失败的链接步骤中自动包含-lgcov。我不确定这个库是否需要保密,但如果我这样更改变量:

    GCOV_CFLAGS="-fprofile-arcs -ftest-coverage --coverage"
    GCOV_LDFLAGS="-fprofile-arcs -ftest-coverage"
    GCOV_LIBS="-lgcov"
    

    ..并确保GCOV_LIBS 包含在LIBS 中,然后一切正常,在我的所有平台上。

    编辑:另见this thread

    【讨论】:

    • 您是手动将这些 GCOV* 变量转换为其他变量还是自动包含在内?如果您手动将它们放入其他人中,您将它们放入哪个?
    • 实际上,我的脚本的当前版本似乎还做了第三件事。看看github.com/phs/sauce/blob/master/Makefile.am(请参阅configure.ac 以获取GCOV_ENABLED
    • 此评论由冗余部提供给您。 --coverage 相当于编译时的 -fprofile-arcs -ftest-coverage 和链接时的 -lgcov
    【解决方案2】:

    以更通用的方式,可以通过确保您的库在链接命令行上正确排序来修复此错误。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2021-08-25
      • 1970-01-01
      • 1970-01-01
      • 2023-01-31
      • 2014-07-04
      • 2022-01-24
      • 2018-08-18
      • 1970-01-01
      相关资源
      最近更新 更多