Question

我正在尝试使用Boost的单元测试框架构建单元测试。我想动态地将测试套件库与Boost提供的自动生成的测试模块链接起来。这是我一直在使用的基本结构：

test_main.cpp：

#define BOOST_TEST_DYN_LINK
#define BOOST_TEST_MAIN

#include <boost/test/unit_test.hpp>

lib_case.cpp：

#define BOOST_TEST_DYN_LINK
#include <boost/test/unit_test.hpp>


BOOST_AUTO_TEST_SUITE( test_lib )

BOOST_AUTO_TEST_CASE( test_lib_case ) {
    BOOST_ASSERT(true);
}
BOOST_AUTO_TEST_SUITE_END()

生成文件：

    all: unittest unittest2 unittest3

    lib_case.o: lib_case.cpp
        g++ -g -c -Wall -fPIC lib_case.cpp -o lib_case.o

    libcase.so: lib_case.o
        g++ -shared -Wl,-soname,libcase.so -o libcase.so lib_case.o

    unittest: libcase.so
        g++ -o unittest test_main.cpp -L. -lcase -lboost_unit_test_framework

    unittest2: test_main.cpp lib_case.cpp
        g++ -o unittest2 test_main.cpp lib_case.cpp -lboost_unit_test_framework

    unittest3: lib_case.o
        g++ -o unittest3 test_main.cpp lib_case.o -lboost_unit_test_framework

在Ubuntu 14.04上进行测试，所有可执行文件都可以无错误地编译和链接。

＆＃39;单元测试＆＃39;未能执行＆＃39; test_lib＆＃39;套件声称设置失败，但＆＃39; unittest2＆＃39;和＆＃39; unittest3＆＃39;成功：

$./unittest
Test setup error: test tree is empty
$./unittest2
Running 1 test case...
*** No errors detected
$./unittest3
Running 1 test case...
*** No errors detected

现在头疼：所有unittest *在Fedora 20上运行测试套件。

在查看＆＃39; unittest＆＃39;的依赖关系列表时，我确实看到＆＃39; libcase.so＆＃39;没有在Ubuntu版本中列出，但是在Fedora 20版本中。我已经玩过重新排序依赖项，使用SO的绝对路径，以及更改Boost版本（1.54和1.55）。没有任何效果。

关于什么可能会阻止＆libff.so＆＃39;从Ubuntu 14.04链接而不是在Fedora 20上链接？我错过了一些神奇的编译器/链接器标志吗？

更新

Sehe的评论和回答有助于缩小问题范围。如果我正确理解Boost动态链接的UTF实现（至少从1.54 / 55开始），那么框架提供了一个测试用例管理器单例。每个测试用例都会在构建时自动向管理员注册。

我认为问题在于，无论出于何种原因，在Ubuntu上进行链接可以优化＆＃39;在将库链接到二进制文件期间用于管理器的单例实例的静态全局变量。实际上，尽管共享相同的全局静态变量，但它并不链接两个单例实例。它将它们视为两个独立的实例。

我按照Multiple instances of singleton across shared libraries on Linux中描述的步骤检查库和二进制文件。与他们的情况不同，-rdynamic选项无法解决我的问题。

我做了一些测试，发现这很有趣。如果你预加载libcase.so对象，unittest适用于Ubuntu。即使libcase.so没有出现在其ldd列表中。我觉得这是预期的，因为经理的单身人员是预先加载的＃39;当unittest运行时，它将链接它。

$ LD_PRELOAD=/absolute/path/to/libcase.so ./unittest
Running 1 test case ...

仍然不知道为什么Ubuntu不想像Fedora那样预期/预期链接。阅读this tutorial（特别是与Microsoft DLL的比较＆＃39;部分）让我觉得Ubuntu遵循Windows链接模式。

Answer 1

知道了！

默认情况下，Ubuntu似乎使用--as-needed链接器选项，而Fedora可能不会。关闭它会将libcase.so库添加到unittest所需的列表中。部署库（或使用LD_LIBRARY_PATH）后，unittest现在可以正常工作。

unittest: libcase.so
        g++ -o unittest test_main.cpp -Wl,--no-as-needed -L. -lcase -lboost_unit_test_framework

数字很简单...

Answer 2

问题是lib_case.o已经过优化，因为没有对那里包含的任何内容的引用。

如果所有引用都从测试用例定义引用到单元测试框架（用于自注册）但没有返回，则编译并链接测试主轴＆＃34;未使用＆＃34;库。

我可以在我的系统上重现这个（Ubuntu 14）。这是一个简单的黑客，通过强制引用（在本例中为一个名为force_reference_this_object_file的全局变量来展示如何修复它。

备注

当然你通常在头文件中声明全局
您会发现需要部署libcase.so或使用LD_LIBRARY_PATH在库路径中包含./

lib_case.cpp

#define BOOST_TEST_DYN_LINK
#include <boost/test/unit_test.hpp>

int force_reference_this_object_file = 42;

BOOST_AUTO_TEST_SUITE( test_lib )

BOOST_AUTO_TEST_CASE( test_lib_case ) {
    BOOST_ASSERT(true);
}
BOOST_AUTO_TEST_SUITE_END()

test_main.cpp

#define BOOST_TEST_DYN_LINK
#define BOOST_TEST_MAIN

#include <boost/test/unit_test.hpp>

extern int force_reference_this_object_file;

namespace {
    struct Local
    {
        int& ref_;
        Local() : ref_(force_reference_this_object_file) {}
    };

    static Local hack_;
}

Makefile

all: unittest unittest3

CPPFLAGS=-Wall -fPIC
LDFLAGS+=-L ~/WORK/pocpp/3rdparty/boost_1_58_0/stage/lib/

%.o: %.cpp
    g++ -c $(CPPFLAGS) $^ -o $@

libcase.so: lib_case.o
    g++ $(CPPFLAGS) -shared -Wl,-soname,$@ -o $@ $^

unittest: test_main.o | libcase.so
    #g++ $(CPPFLAGS) -o $@ $< $(LDFLAGS) -L. -lcase -lboost_unit_test_framework
    g++ $(CPPFLAGS) -o $@ $< $(LDFLAGS) ./libcase.so -lboost_unit_test_framework

unittest3: test_main.o lib_case.o
    g++ $(CPPFLAGS) -o $@ $^ $(LDFLAGS) -lboost_unit_test_framework

在Ubuntu

2 个答案: