“隐藏符号”atexit“由DSO引用”当与gcov使用libtool [英] "Hidden symbol `atexit' is referenced by DSO" when using libtool with gcov

查看:1656
本文介绍了“隐藏符号”atexit“由DSO引用”当与gcov使用libtool的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个C ++项目,它使用GNU Autotools的构建脚本和libtool进行链接。最近,我通过确保

  GCOV_CFLAGS = -  fprofile-arcs -ftest-coverage$添加了代码覆盖率检测工具gcov b $ b GCOV_LDFLAGS = -  fprofile-arcs -ftest-coverage

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


$ b 在Ubuntu 12.04使用g ++ 4.6.3时,libtool无法链接我的测试:

$ p $ / 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:/usr/lib/x86_64-linux-gnu/libc_nonshared.a(atexi)中隐藏的符号`atexit' t.oS)由DSO
/ usr / bin / ld引用:最终链接失败:错误值
collect2:ld返回1退出状态
make [2]:*** [myproj / inttests / locale_test]错误1

如何解决我在ubuntu / g ++ 4.6上的构建问题?

解决方案

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

  ./ 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


I have a C++ project that uses the GNU Autotools for its build scripts and libtool for linking. Recently I have added code coverage instrumentation with gcov, by ensuring that

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

..get included in my CFLAGS and LDFLAGS respectively. On OS X 10.7.4 using g++-4.2 (installed by homebrew), everything works fine.

On Ubuntu 12.04 using g++ 4.6.3, libtool fails to link one of my tests:

/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

How do I fix my build on ubuntu/g++ 4.6?

解决方案

After googling around I see this thread, which suggests adding --coverage to CXXFLAGS when running ./configure. Indeed, though it didn't work for that poster, it works for me:

./configure CXXFLAGS="--coverage"

However this variable is reserved for the package installer, not the maintainer (me.) The question reduces to "How do I incorporate this into the build properly?"

Here's what's not enough:

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

On the assumption that GCOV_CFLAGS gets included into the effective CXXFLAGS (not shown, but it does), it seems like this fix should work. It doesn't.

Digging in further, it seems we should at least get some traction if we drop CXXFLAGS="--coverage" from the command line and instead place it in configure.ac somewhere. This, actually, also did not work unless the line is placed above the AC_PROG_CXX call that selects the compiler.

So now we gain a little insight. AC_PROG_CXX is altering something when it sees --coverage, which is very likely why the placement in GCOV_CFLAGS didn't work: it was too late.

Looking carefully through the logs, it appears the secret sauce is the automatic inclusion of -lgcov in the failing linking step. I'm not sure this library needed to be such a secret, but if I change my variables as so:

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

..and ensure GCOV_LIBS is included in LIBS, then it all works, on all my platforms.

EDIT: See also this thread.

这篇关于“隐藏符号”atexit“由DSO引用”当与gcov使用libtool的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆