[Test] failure linking tests dynamically

Latimerius

7 Nov 2014 7 Nov '14

5:51 p.m.

Hello, I'm evaluating Boost.Test. I did the initial evaluation using the header-only variant and now I'd like to move to dynamic linking the Test library for a larger-scale deployment. However, all attempts so far failed due to Undefined symbols for architecture x86_64: "_main", referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64 I'd put it down to my lack of experience with Test, or Boost in general, however I noticed that my libs/test/example's don't seem to build either. I'm on OS X Yosemite. I compile Boost with ./bootstrap.sh --prefix= ./b2 cxxflags="-stdlib=libc++" linkflags="-stdlib=libc++" ./b2 install As this doesn't seem to compile the necessary .dylibs I added <define>BOOST_TEST_DYN_LINK=1 <link>shared to the "requirements" section of the first target in libs/test/build/Jamfile.v2 and rebuilt just Boost.Test. Although I don't actually know what I was doing, this did seem to build the Boost.Test dynamic libraries, which tests are however failing to link against. The result looks the same on 1_56_0 and 1_57_0. Could someone please help me find the problem? I'm dubious about my building procedure in particular, could someone give me a complete sequence of steps necessary to build Boost with Boost.Test ready to be linked dynamically? I check the documentation, which is good and detailed but deals with various aspects in isolation and doesn't give a newcomer a good idea of the overall process. Cheers!

Show replies by date

legalize+jeeves＠mail.xmission.com

7 Nov 7 Nov

4:14 p.m.

[Please do not mail me a copy of your followup] Latimerius spake the secret code <20141107175110.GA3432@kostra.uh.cz> thusly:

...

[...] However, all attempts so far failed due to

Undefined symbols for architecture x86_64: "_main", referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64

When you compiled your test program, did you define BOOST_TEST_MAIN in one of your source files before including the boost.test headers? Someone needs to supply a definition of main and if you ask boost.test to do it by defining that symbol before including the headers, it will provide one for you. Try looking at my documentation here and see if this clears things up: http://user.xmission.com/~legalize/boost.test/libs/test/doc/html/test/guide/...

...

I'm on OS X Yosemite. I compile Boost with [...]

Could someone please help me find the problem?

I don't have any Mac machines, but my understanding is that the instructions I gave on the above page should work regardless of what platform you are using via the use of bjam build logic. -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

Latimerius

8 Nov 8 Nov

3:54 p.m.

Hello Richard, Thanks for your reply! Please see my comments inline. On Fri, Nov 07, 2014 at 04:14:41PM +0000, Richard wrote:

...

[Please do not mail me a copy of your followup]

Latimerius spake the secret code <20141107175110.GA3432@kostra.uh.cz> thusly:

...
[...] However, all attempts so far failed due to

Undefined symbols for architecture x86_64: "_main", referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64

When you compiled your test program, did you define BOOST_TEST_MAIN in one of your source files before including the boost.test headers?

I was speaking here about the examples supplied with the library. My problem is that when I download Boost and compile it (using the procedure described in my previous message), the examples (in /libs/test/example) don't build for me for some reason, and the error message is the one concerning missing main(). As far as my own attempts go, those do build curiously enough, but the resulting program crashes while exiting the main function, and its output is garbled: Running 2 test cases... InputWindowTest.cpp:14: error in "=@???DP?:7|??DP???DP?:7|": check *** 1 failure detected (1953719668 failures expected) in test suite "Segmentation fault: 11 The program is as follows: #include "InputWindow.h" #define BOOST_TEST_MODULE EventActionMgr #include BOOST_AUTO_TEST_CASE (EventAction_test) { ui::EventAction a; BOOST_CHECK (a.RunHandlers () == true); } built with clang++ -g -Wall -std=c++11 -stdlib=libc++ -DBOOST_TEST_DYN_LINK -I.. -I ../../.. -I/usr/local/boost_1_57_0/include -L/usr/local/boost_1_57_0/lib InputWindowTest.cpp -o InputWindowTest -lboost_unit_test_framework I suspect memory corruption. The way the output is garbled varies with the argument of BOOST_TEST_MODULE. Whether I do or do not #define BOOST_TEST_MAIN doesn't seem to matter. As for where the crash happens: a test run with zero detected failures crashes after main(). A run with failures usually crashes while trying to print a failure. I suspect something wrong might be happening at the boundary between the main program and the shared library (libboost_unit_test_framework.dylib).

...

Someone needs to supply a definition of main and if you ask boost.test to do it by defining that symbol before including the headers, it will provide one for you.

Try looking at my documentation here and see if this clears things up: http://user.xmission.com/~legalize/boost.test/libs/test/doc/html/test/guide/...

Thanks for the link, that's good info! I somehow missed it before. Thanks again, pvl

Latimerius

4:37 p.m.

Actually, please disregard the part about my own tests building but crashing. I figured it out, it was due to a mismatch between standard C++ library versions used by the shared library and the main program. I do know I have to watch out for this as Boost build defaults to the wrong one but during the attempts to make things work I apparently wasn't careful enough and did a bad build. Sorry about that. On Sat, Nov 08, 2014 at 04:54:07PM +0100, Latimerius wrote:

...

Hello Richard,

Thanks for your reply! Please see my comments inline.

On Fri, Nov 07, 2014 at 04:14:41PM +0000, Richard wrote:

...
[Please do not mail me a copy of your followup]

Latimerius spake the secret code <20141107175110.GA3432@kostra.uh.cz> thusly:

...
[...] However, all attempts so far failed due to

Undefined symbols for architecture x86_64: "_main", referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64

When you compiled your test program, did you define BOOST_TEST_MAIN in one of your source files before including the boost.test headers?

I was speaking here about the examples supplied with the library. My problem is that when I download Boost and compile it (using the procedure described in my previous message), the examples (in /libs/test/example) don't build for me for some reason, and the error message is the one concerning missing main().

As far as my own attempts go, those do build curiously enough, but the resulting program crashes while exiting the main function, and its output is garbled:

Running 2 test cases... InputWindowTest.cpp:14: error in "=@???DP?:7|??DP???DP?:7|": check *** 1 failure detected (1953719668 failures expected) in test suite "Segmentation fault: 11

The program is as follows:

#include "InputWindow.h"

#define BOOST_TEST_MODULE EventActionMgr #include

BOOST_AUTO_TEST_CASE (EventAction_test) { ui::EventAction a; BOOST_CHECK (a.RunHandlers () == true); }

built with

clang++ -g -Wall -std=c++11 -stdlib=libc++ -DBOOST_TEST_DYN_LINK -I.. -I ../../.. -I/usr/local/boost_1_57_0/include -L/usr/local/boost_1_57_0/lib InputWindowTest.cpp -o InputWindowTest -lboost_unit_test_framework

I suspect memory corruption. The way the output is garbled varies with the argument of BOOST_TEST_MODULE. Whether I do or do not #define BOOST_TEST_MAIN doesn't seem to matter.

As for where the crash happens: a test run with zero detected failures crashes after main(). A run with failures usually crashes while trying to print a failure. I suspect something wrong might be happening at the boundary between the main program and the shared library (libboost_unit_test_framework.dylib).

...
Someone needs to supply a definition of main and if you ask boost.test to do it by defining that symbol before including the headers, it will provide one for you.

Try looking at my documentation here and see if this clears things up: http://user.xmission.com/~legalize/boost.test/libs/test/doc/html/test/guide/...

Thanks for the link, that's good info! I somehow missed it before.

Thanks again,

pvl

legalize+jeeves＠mail.xmission.com

11 Nov 11 Nov

6:21 p.m.

[Please do not mail me a copy of your followup] Latimerius spake the secret code <20141108155407.GA22141@kostra.uh.cz> thusly:

...

The program is as follows:

#include "InputWindow.h"

#define BOOST_TEST_MODULE EventActionMgr #include

[...]

I suspect memory corruption. The way the output is garbled varies with the argument of BOOST_TEST_MODULE. Whether I do or do not #define BOOST_TEST_MAIN doesn't seem to matter.

When you define BOOST_TEST_MODULE, it defines BOOST_TEST_MAIN for you. I need to update my docs on this point. -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

3670

Age (days ago)

3674

Last active (days ago)

List overview

Download

4 comments

2 participants

participants (2)

Latimerius
legalize+jeeves＠mail.xmission.com