Автоконф с буст тестом — проблема с компоновщиком

Я столкнулся с проблемой с фреймворком boost unit_test вместе с autoconf & Automake …

Вот о структуре проекта:

  • ./include/com_i_foo.h
  • ./include/com_foo.h

...
class FooSingleton {
protected:
FooSingleton() {}
private:
FooSingleton* _instance;
public:
virtual ~FooSingleton() {}
static FooSingleton* getInstance();
};

class FooFoo {
public:
FooFoo() {}
virtual uint32_t getSomeInt();
virtual ~FooFoo() {}
};
typedef boost::shared_ptr FooFooPtr_t;
...
  • ./include/com_api.h

#include "com_foo.h"
  • ./include/Makefile.am

include_HEADERS = \
com_i_foo.h \
com_foo.h \
com_api.h \
$(NULL)
  • ./src/com_foo.cpp
  • ./src/Makefile.am

PLATEFORM=LINUX64
DEBUG_OPTIONS = -g
DEFINE_OPTIONS=-D${PLATEFORM}
OPTIONS = -Wall -Werror -shared -O2 $(DEBUG_OPTIONS) $(DEFINE_OPTIONS)

COMMON_CXXFLAGS= ${OPTIONS} -I$(top_builddir)/include
ACLOCAL_AMFLAGS = -I ${top_builddir}/m4
AM_LDFLAGS=

lib_LTLIBRARIES  = \
libcom_api.la \
$(NULL)

libcom_api_la_SOURCES = com_foo.cpp
libcom_api_la_CXXFLAGS = ${COMMON_CXXFLAGS}
libcom_api_la_LDFLAGS =
libcom_api_la_LIBADD =
  • ./test/Makefile.am

PLATEFORM=LINUX64
DEBUG_OPTIONS = -g
DEFINE_OPTIONS=-D${PLATEFORM} -DBOOST_ENABLE_ASSERT_HANDLER
OPTIONS = -Wall -Werror -O2 $(DEBUG_OPTIONS) $(DEFINE_OPTIONS)

BOOST_LIBS = -lboost_unit_test_framework -lboost_locale -lboost_filesystem -lboost_system -lboost_thread

COMMON_CXXFLAGS= ${OPTIONS} -I$(top_srcdir)/include -I$(top_srcdir)/src
AM_LDFLAGS=
ACLOCAL_AMFLAGS = -I ${top_builddir}/m4

check_PROGRAMS = ut_com_api

ut_com_api_SOURCES = \
ut_com_api.cpp \
$(NULL)
ut_com_api_CXXFLAGS = ${COMMON_CXXFLAGS}
ut_com_api_LDFLAGS = -rdynamic
ut_com_api_LDADD = ${BOOST_LIBS} $(top_builddir)/src/libcom_api.la
  • ./test/ut_com_api.cpp

#define BOOST_LIB_DIAGNOSTIC
#define BOOST_TEST_DYN_LINK
#define BOOST_TEST_MODULE "Common API Unit tests"
#include

#include "com_api.h"
using namespace boost::unit_test;

BOOST_AUTO_TEST_SUITE(com_api)

BOOST_AUTO_TEST_CASE(FooFooTest) {
FooFooPtr_t myFoo(new FooFoo());
BOOST_CHECK(myFoo->getSomeInt() == 2);
}

BOOST_AUTO_TEST_CASE(FooSingletonTest) {
FooSingleton* myFoo = FooSingleton::getInstance();
BOOST_CHECK(myFoo != NULL);
}

BOOST_AUTO_TEST_SUITE_END()
  • ./Makefile.am

SUBDIRS = include src test
#dist_doc_DATA = README
ACLOCAL_AMFLAGS = -I m4
  • ./configure.ac

AC_INIT([com_api], [1.0], [bug@foo.foo])
AC_CONFIG_MACRO_DIR([m4])
AM_INIT_AUTOMAKE([-Wall -Werror foreign])
AC_PROG_LIBTOOL
AC_PROG_CXX
AC_LANG_PUSH(C++)
AX_BOOST_BASE([1.53], ,[AC_MSG_ERROR([You need boost library])])
AX_BOOST_PROGRAM_OPTIONS
AX_BOOST_DATE_TIME
AC_CHECK_HEADER([boost/shared_ptr.hpp], , [AC_MSG_ERROR([You need boost library])])
AC_LANG_POP(C++)
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([
Makefile
include/Makefile
src/Makefile
test/Makefile
])
AC_OUTPUT

Моя проблема:

Когда я собираю DLL (.so под linux), она работает отлично, но когда я пытаюсь собрать check_PROGRAMS, компоновщик возвращает следующие неопределенные ссылки:

  • неопределенная ссылка на экземпляр FooSingleton :: _
  • В функции `boost :: shared_ptr :: operator -> () const:
    неопределенная ссылка на boost :: assertion_failed (char const *, char const *, char const *, long)

Что касается FooSingleton, я не понимаю почему, потому что я хорошо связываю свою программу проверки со встроенной DLL …

Что касается boost, я полагаю, что мне не хватает -lboost_xxxx в моем test / Makefile.am, но я не понимаю, почему мне пришлось бы явно указывать библиотеку boost для линкера для check_PROGRAMS, в то время как он отлично работает со сборкой DLL. ..

Я везде искал решение, но у меня заканчиваются идеи, поэтому любая помощь будет оценена!

2

Решение

Похоже на макрос BOOST_ENABLE_ASSERT_HANDLER как-то определяется

Как указано в документация для Boost.Assert, если BOOST_ENABLE_ASSERT_HANDLER определяется, когда <boost/assert.hpp> включен, то BOOST_ASSERT(expr) расширяется до вызова boost::assertion_failed, но эта функция не реализована; ожидается, что пользователь предоставит реализацию.

Попробуй посмотреть, что-то вызывает BOOST_ENABLE_ASSERT_HANDLER быть определенным при построении check_PROGRAMS.

4

Другие решения

Других решений пока нет …