From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-16 02:16:29
"Douglas Gregor" <doug.gregor_at_[hidden]> wrote in message
On May 15, 2007, at 3:33 AM, Jürgen Hunold wrote:
> > Just #define BOOST_TEST_DYN_LINK
> For the shared library tests.
> For the static library tests, I don't define BOOST_TEST_DYN_LINK, and
> I put the .a file directly on the link line instead of using -L and -l.
> > Taking a look at libs/test/build/Jamfile.v2 reveals
> > : usage-requirements
> > <define>BOOST_TEST_NO_AUTO_LINK=1
> > <link>shared:<define>BOOST_TEST_DYN_LINK=1
> > which Boost.Build applies automagically ;-))
> Users of Boost.Build are isolated from this change are isolated from
> the effects of this change due to usage-requirements. usage-
> requirements are very cool, but they hide the fact that this change
> causes real trouble for people not using Boost.Build. The very simple
Note that unit tests that are using static library variant somehow works.
That means that Boost.Build managed to link with proper lib.
> g++ mytest.cpp -I $BOOST_HDRDIR -L $BOOST_ROOT/lib -
> fails to link. That's bad for at least two reasons: (1) it's the
> first line that someone is likely to write when trying out the unit
> test framework, and it's not going to work; (2) it's the line that
> most non-BBv2 build systems would produce, because using -L and -l
> are the common ways to link against a static library in the Unix
> world. Not the *only* way, but the common way.
I believe your expectations are not exactly correct in this case. If you are
working with portable library, you cant expect both static and shared
libraries works the same way, since there are major diffrences on NT
platform. as for the way to fix above line I see several options:
1. add -static before -l
2. explicetly refer to the static lib.
3. Make Boost.Build produce different names for static/dynamic libs.
Alternatively you can name them differently in your make system by yourself.
> There also doesn't
> seem to be any documentation that tells users that this change was
> made, or how to link to the Boost unit test framework on a *nix system.
This was in length discussed. The change occured more than your ago. That
said I admit lack of proper docs. The tutorial session on Fraday is the
first step to address this. The users docs should be ready some time soon.
> We've already had some user confusion on this change, e.g.,
The users of dynamic library variant in most cases only required to define
BOOST_TEST_DYN_LINK (which is usual requirement for all boost libs). The
Boost.Build users shouldn't have problems either. In my make system I can
explicetly specify whether or not I want shared library to be linked with.
In other cases one of the above should work.
> where I stole the link line above. As I was typing this note, I see
> another note requesting assistance on getting this library to link.
> Not a good sign.
> I think we should revert this change for 1.34.1, so that main()
> appears in both the static and the shared library. This makes the
> simple use cases (which used to work!) work again.
The difference between dynamic and static library variants are beyond
presence of function main(). The initialization function and built in test
runner signatures are is different. External test runners supprt
requirements etc. Note also that it doesn't really fix problem in your
case - it hides it. You never intended to link with shared library. And it
worked only by chance. From general prospective there is no other way to
make the library work portably. What I do want to see in 1.34.1 is the docs
I plan to talk about different usage variants on friday. Also we may
discusse this during the break if you up to it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk