boost-test - 'undefined reference" Fehler

Habe ich zwei einfache Dateien:

runner.cpp:

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

und test1.cpp:

#define BOOST_TEST_DYN_LINK
#ifdef STAND_ALONE
#   define BOOST_TEST_MODULE Main
#endif
#include <boost/test/unit_test.hpp>

BOOST_AUTO_TEST_SUITE( Foo)

BOOST_AUTO_TEST_CASE( TestSomething )
{
    BOOST_CHECK( true );
}

BOOST_AUTO_TEST_SUITE_END()

Zu kompilieren, bin ich mit:

$ g++ -I/e/code/boost_1_52_0 -o runner -lboost_unit_test_framework runner.cpp test1.cpp

Bekomme ich die folgende Fehlermeldung:

C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccU0cDSz.o:runner.cpp:(.text+0x8c): multiple definition of `main'
c:/pdev/mingw/bin/../lib/gcc/i686-pc-mingw32/4.7.2/../../../libboost_unit_test_framework.a(unit_test_main.o):unit_test_main.cpp:(.text.startup+0x0): first defined here
c:/pdev/mingw/bin/../lib/gcc/i686-pc-mingw32/4.7.2/../../../libboost_unit_test_framework.a(unit_test_main.o):unit_test_main.cpp:(.text.startup+0x14): undefined reference to `init_unit_test_suite(int, char**)'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccU0cDSz.o:runner.cpp:(.text+0x52): undefined reference to `_imp___ZN5boost9unit_test9framework17master_test_suiteEv'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccU0cDSz.o:runner.cpp:(.text+0xb0): undefined reference to `_imp___ZN5boost9unit_test14unit_test_mainEPFbvEiPPc'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccU0cDSz.o:runner.cpp:(.text$_ZN5boost9unit_test13test_observerD2Ev[__ZN5boost9unit_test13test_observerD2Ev]+0xe): undefined reference to `_imp___ZTVN5boost9unit_test13test_observerE'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccU0cDSz.o:runner.cpp:(.text$_ZN5boost9unit_test13test_observerC2Ev[__ZN5boost9unit_test13test_observerC2Ev]+0xe): undefined reference to `_imp___ZTVN5boost9unit_test13test_observerE'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccU0cDSz.o:runner.cpp:(.text$_ZN5boost9unit_test15unit_test_log_tC1Ev[__ZN5boost9unit_test15unit_test_log_tC1Ev]+0x22): undefined reference to `_imp___ZTVN5boost9unit_test15unit_test_log_tE'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cciSdkmB.o:test1.cpp:(.text+0x88): undefined reference to `_imp___ZN5boost9unit_test15unit_test_log_t14set_checkpointENS0_13basic_cstringIKcEEjS4_'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cciSdkmB.o:test1.cpp:(.text+0x136): undefined reference to `_imp___ZN5boost10test_tools9tt_detail10check_implERKNS0_16predicate_resultERKNS_9unit_test12lazy_ostreamENS5_13basic_cstringIKcEEjNS1_10tool_levelENS1_10check_typeEjz'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cciSdkmB.o:test1.cpp:(.text+0x21d): undefined reference to `_imp___ZN5boost9unit_test9ut_detail24auto_test_unit_registrarC1ENS0_13basic_cstringIKcEE'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cciSdkmB.o:test1.cpp:(.text+0x284): undefined reference to `_imp___ZN5boost9unit_test9ut_detail24auto_test_unit_registrarC1EPNS0_9test_caseEm'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cciSdkmB.o:test1.cpp:(.text+0x2a4): undefined reference to `_imp___ZN5boost9unit_test9ut_detail24auto_test_unit_registrarC1Ei'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cciSdkmB.o:test1.cpp:(.text$_ZN5boost9unit_test14make_test_caseERKNS0_9callback0INS0_9ut_detail6unusedEEENS0_13basic_cstringIKcEE[__ZN5boost9unit_test14make_test_caseERKNS0_9callback0INS0_9ut_detail6unusedEEENS0_13basic_cstringIKcEE]+0x1d): undefined reference to `_imp___ZN5boost9unit_test9ut_detail24normalize_test_case_nameENS0_13basic_cstringIKcEE'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cciSdkmB.o:test1.cpp:(.text$_ZN5boost9unit_test14make_test_caseERKNS0_9callback0INS0_9ut_detail6unusedEEENS0_13basic_cstringIKcEE[__ZN5boost9unit_test14make_test_caseERKNS0_9callback0INS0_9ut_detail6unusedEEENS0_13basic_cstringIKcEE]+0x5b): undefined reference to `_imp___ZN5boost9unit_test9test_caseC1ENS0_13basic_cstringIKcEERKNS0_9callback0INS0_9ut_detail6unusedEEE'
collect2.exe: error: ld returned 1 exit status

Bin ich mit g++ 4.7.2 auf MinGW, mit boost 1.52.0.

Bekomme ich den gleichen Fehler, wenn Sie nur versuchen, das zu kompilieren test1.cpp - mit Ausnahme der "mehrere Haupt-definition".

Ich schon durchgelesen die offizielle Dokumentation für eine ganze Weile, aber die knappen auf details in Bezug auf die Verknüpfung Optionen. Wenn ich kompiliert habe, die boost-libs, neben unit_test_framework habe ich auch prg_exec_monitor und test_exec_monitor; vielleicht sollte ich diesen link irgendwie ? Ich habe versucht, viele Kombinationen, aber alle führten in irgendeiner Art undefined reference linker-Fehler.

Vollständige Liste der boost-Bibliotheken generiert - ich habe Sie alle in das Projekt root:

libboost_prg_exec_monitor-mgw47-mt-1_52.a
libboost_prg_exec_monitor-mgw47-mt-1_52.dll
libboost_prg_exec_monitor-mgw47-mt-1_52.dll.a
libboost_prg_exec_monitor-mgw47-mt-d-1_52.a
libboost_prg_exec_monitor-mgw47-mt-d-1_52.dll
libboost_prg_exec_monitor-mgw47-mt-d-1_52.dll.a
libboost_test_exec_monitor-mgw47-mt-1_52.a
libboost_test_exec_monitor-mgw47-mt-d-1_52.a
libboost_unit_test_framework-mgw47-mt-1_52.a
libboost_unit_test_framework-mgw47-mt-1_52.dll
libboost_unit_test_framework-mgw47-mt-1_52.dll.a
libboost_unit_test_framework-mgw47-mt-d-1_52.a
libboost_unit_test_framework-mgw47-mt-d-1_52.dll
libboost_unit_test_framework-mgw47-mt-d-1_52.dll.a
Mit g++, die Sie benötigen, um Ihre Bibliotheken (-lwhatever) nach Ihrem Quell-oder Objekt-Dateien (d.h. g++ -I/e/code/boost_1_52_0 -o runner runner.cpp test1.cpp -lboost_unit_test_framework). Link hier. Es ist möglich, Sie müssen auch hinzufügen, eine -L/path/to/libraries Analog zu Ihrem -I/e/code/boost_1_52_0.
Antwort scheint sehr ähnlich zu sein zu dem, was Sie tun.
in der Tat, setzen die lib nach Objekten funktioniert. -L. ist es auch notwendig, und die lib muss bestanden als -lboost_unit_test_framework-mgw47-mt-1_52. Indem er als -lboost_unit_test_framework Ergebnisse bei der Verlinkung Fehler. Jedoch, wenn ich den Verdacht es könnte nicht finden, das "lib", gab ich so etwas wie -lfoo und es beschwert keine solche lib vorhanden ist. Nach Rücksprache mit dieser Seite über Standard MinGW lib-Pfade, stellt sich heraus, ich hatte eine andere libboost_unit_test_framework.a in diesen Ordner.
wenn Sie zusammenfassen könnte, diese Themen in eine Antwort werde ich gerne annehmen.
meine Beratung dauerte nur den halben Weg. Setzen die sich selbst beantworten und ich werde upvote.

InformationsquelleAutor Mihai Rotaru | 2012-12-07

  1. 19

    Mit Hilfe von @llonesmiz, eine Reihe von Fragen identifiziert wurden.

    1. Bibliotheken müssen angegeben werden nach Objekte und Quellen, die Sie verwenden.

    Beschrieben hier:

    Dem traditionellen Verhalten des linkers ist die Suche nach externen Funktionen aus
    von Links nach rechts in den Bibliotheken auf der Befehlszeile angegeben. Dies bedeutet, dass ein
    Bibliothek, die die definition einer Funktion sollte angezeigt werden, nach jeder beliebigen Quelle
    Dateien oder Objekt-Dateien, die es verwenden. Dies beinhaltet die Bibliotheken angegeben, die mit den
    short-cut -l-option, wie gezeigt, in der Sie folgenden Befehl ein:

    $ gcc -Wall calc.c -lm -o calc (correct order)

    Mit einigen linkers das Gegenteil der Bestellung (wenn Sie den -lm-option, bevor Sie die Datei
    was nutzt es) würde zu einem Fehler führen,

    $ cc -Wall -lm calc.c -o calc (incorrect order)

    main.o: In function 'main':

    main.o(.text+0xf): undefined reference to 'sqrt'

    weil es keine Bibliothek oder Objektdatei mit sqrt nach ‘calc.c'. Die
    option -lm sollte angezeigt, nachdem die Datei " calc.c'

    2. Library-Pfade explizit angegeben werden.

    Wenn keine lib-Pfade angegeben sind, die linker Aussehen könnte, für die libs in einer Reihe
    der Standard-Ordner, damit das laden einer anderen Bibliothek dann bestimmt. Dies ist, was
    in meinem Fall passiert - ich wollte den link boost_unit_test_framework, aber nicht
    einen Pfad angeben, weil ich davon ausgegangen, das der linker würde mal in den aktuellen Ordner.
    Das ist, was passiert zur Laufzeit, nachdem alle - wenn die dll ist im gleichen Ordner
    mit der exe werden, wird es finden.

    Fand ich es ein wenig seltsam, der linker würde der lib, da war es
    benannt ibboost_unit_test_framework-mgw47-mt-1_52.dll. Als ich versuchte, Sie zu verlinken
    eine nicht vorhandene lib, der linker beschwert, obwohl, so bin ich davon ausgegangen, dies ist nicht ein
    Problem, und MinGW 's linker ignoriert diejenigen Suffixe.

    Nach etwas mehr Forschung fand ich dieser Artikel über MinGW Bibliothek-Pfade.
    Die Ordner MinGW sucht nach libs gefunden werden kann in der Ausgabe von gcc -print-search-dirs.
    Der Artikel enthält auch einige bash Magie, Sinn zu machen, Ausgabe:

    gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,;  ,g' | tr \; \\012 | grep -v '^ */'

    Druckt eine nette Liste von diesen Ordnern. gcc wird nicht, standardmäßig
    schauen Sie in das aktuelle Verzeichnis für die libs. Ich sah in jedem von Ihnen, und fanden die
    lib, die war geladen - libboost_unit_test_framework.a eine statische lib.

    Dieser bringt Sie ins Licht ein weiteres Problem erwähnenswert:

    3. Statische versus dynamische Verknüpfung

    Ich nicht angeben, ob ich will boost_unit_test_framework statisch gelinkt oder dynamisch.
    In diesem Fall gcc, die bevorzugt dynamische Verknüpfung:

    Wegen dieser Vorteile gcc kompiliert Programme für die Verwendung gemeinsamer Bibliotheken, die von
    Standard auf den meisten Systemen, wenn Sie verfügbar sind. Wenn Sie eine statische Bibliothek
    ‘libNAME.a' verwendet werden, für die Verknüpfung mit der option-iname der compiler
    erste Prüfungen für eine alternative gemeinsame Bibliothek mit dem gleichen Namen und einer ‘.so'
    - Erweiterung.

    (so ist die Dateierweiterung für dynamische Bibliotheken unter Unix - auf Windows, der Gegenwert ist dll.)

    So, was passiert ist, ist, dass gcc gesucht libboost_unit_test_framework.dll
    in allen, die die Standard-Ordner, aber konnte ihn nicht finden. Dann sah es für
    libboost_unit_test_framework.a und statisch gelinkt. Dies führte in
    linking-Fehler, weil die Quellen haben #define BOOST_TEST_DYN_LINK, und
    daher erwarten, dass die lib dynamisch miteinander verknüpft.

    Durchzusetzen statische oder dynamische Verknüpfung, die -Wl,-Bstatic und -Wl,-Bdynamic
    linker-Optionen ins Spiel kommen, beschrieben hier.

    Wenn ich den linker, ich will dynamische Verknüpfung:

    $ g++ -I/e/code/boost_1_52_0 runner.cpp test1.cpp -o runner -Wl,Bdynamic -lboost_unit_test_framework

    Dieser fehl, da der linker nicht in der Lage sein zu finden, die dll.

    4.Zusammenfassung

    Die Themen waren:

    1. Bibliotheken, in denen angegeben wird, bevor die Quellen, die Sie verwendet,
    2. der lib-Pfad nicht angegeben
    3. die Art der Verlinkung war nicht angegeben
    4. den Namen der Bibliothek nicht korrekt war

    Finale, Arbeits-Befehl:

    $ g++ -I/e/code/boost_1_52_0 -o runner runner.cpp test1.cpp -L. -Wl,-Bdynamic -lboost_unit_test_framework-mgw47-mt-1_52
    Ausgezeichnete Antwort. War das problem der multiple definition of main auch gelöst? Ich Plane etwas ähnliches in der nahen Zukunft, und ich bin sicher, dies wird eine große Hilfe sein.
    ja, es war. Ich bin noch nicht sicher, warum es geschah; konnte nicht reproduzieren, die mit den neueren Bibliotheken.
    Ihr Verzeichnis zeigt zwei Versionen von jeder Bibliothek. Mit einem -d- in der Mitte der name und eine ohne. Zum Beispiel libboost_unit_test_framework-mgw47-mt-1_52.a und libboost_unit_test_framework-mgw47-mt-d-1_52.a. Woher wissen Sie, welche dieser zu nutzen?
    wenn ich mich richtig erinnere, der Unterschied ist, dass diejenigen, die mit -d- debugging-Symbole - aber ich bin mir nicht sicher, um ehrlich zu sein.

    InformationsquelleAutor Mihai Rotaru

Schreibe einen Kommentar