$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2008-01-14 11:35:40
Benoit Sigoure <tsuna <at> lrde.epita.fr> writes:
> 
> On Jan 14, 2008, at 9:31 AM, Jens Seidel wrote:
> 
> > $ g++ -DBOOST_TEST_DYN_LINK test.cpp -lboost_unit_test_framework
> > /tmp/ccKcB2Ps.o: In function `main':
> > test.cpp:(.text+0x3d4): undefined reference to  
> > `boost::unit_test::unit_test_main(bool (*)(), int, char**)'
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/ 
> > libboost_unit_test_framework.a(framework.o): In function  
> > `boost::unit_test::framework::init(int, char**)':
> > (.text+0x6fa): undefined reference to `init_unit_test_suite(int,  
> > char**)'
> > collect2: ld returned 1 exit status
> 
> I /worked around/ this issue by always defining a dummy  
> init_unit_test_suite symbol (which was an idea and a contribution of  
> Hubert Figuiere).  This seems totally wrong to me but "It Gets The  
It *is* totally wrong.
> Job Done".  I'm just sad that I have to write such kludge to satisfy  
> the weird need of a library.  Most of the lib I know which need to  
You don't. You just misuse the library. Did you try snippets I recommend?
> interact directly with `main' require you to invoke a function  
> directly from within main. Qt is a great example, you must  
> instantiate a QApplication and give it argc and argv.  It's a very  
> common idiom.  Yet Boost.Test decided that it was a good idea to  
> embed a `main' in a library (!).  What if I want to link with two  
> libraries that decided that it was their own right to define `main'?   
> Come on, this is almost ridiculous and it seems that Gennadiy is not  
> willing to make any effort to understand the problem.
I understand perfectly your problem. It seems you are not willing to listen to 
the solution I present. You need to understand I am long time in this 
buseness. I heard and thought of most possible issues with desing of the 
library. This one is pretty old. I believe that though solution I came up with 
may not be ideal for all involved, is the best under circomstances. 
1. Embedding main into libtary has it's perks. Would you need to implement the 
same main() routine 10 times a day for a year, I can imagine you would also 
look for some way to avoid it. Avoiding to explain test runner API helps as 
well. It shortens learning curve for new users.
2. My primary limitation is to be portable.
3. Starting 1.34 there is a valid simple solution to the situation above: use 
shared library and you are good.
 
Gennadiy