link issues with BOOST_AUTO_TEST_CASE() facility

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

link issues with BOOST_AUTO_TEST_CASE() facility

Pierre-Jules Tremblay
I would like to use the BOOST_AUTO_TEST_CASE() facility in a static
library.  Obviously this library does not have a main() so it needs to
be linked with a test executable which may run test cases found in one
or more of those static libraries.

Unfortunately, the tests do not make it past the linker.  The
executable links fine but runs none of the tests defined in the
libraries.  Could it be that BOOST_AUTO_TEST_CASE() works via some
global which gets stripped when the static lib is created?

Do you have a suggestion for a workaround?  The idea is to keep some
of the lowest-level unit test code in the same translation unit as the
class implementation.

Thanks,

pj
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: link issues with BOOST_AUTO_TEST_CASE() facility

Gennadiy Rozental
>I would like to use the BOOST_AUTO_TEST_CASE() facility in a static
> library.  Obviously this library does not have a main() so it needs to
> be linked with a test executable which may run test cases found in one
> or more of those static libraries.
>
> Unfortunately, the tests do not make it past the linker.  The
> executable links fine but runs none of the tests defined in the
> libraries.  Could it be that BOOST_AUTO_TEST_CASE() works via some
> global which gets stripped when the static lib is created?
>
> Do you have a suggestion for a workaround?  The idea is to keep some
> of the lowest-level unit test code in the same translation unit as the
> class implementation.

Unfortunately I don't think it could work this way. Both your library and
final executable link with Boost.Test statically. You end up with 2 version
of Boost.Test runtime and which one is in use is the matter of linker
implementation. What you could do though is build dynamic library and link
with dynamic version of Boost.Test (cvs already support that). This
configuration is tested and work as expected.

Gennadiy



_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: link issues with BOOST_AUTO_TEST_CASE() facility

Pierre-Jules Tremblay
Hmmm... I don't understand.  What do you mean by "static lib linking
Boost.Test statically" ?

To my knowledge, the linker does attempt to resolve symbols referenced
BY static libraries, it only does so for dlls and executables.  It
can, however, strip from the static library bits of code which are
local to a translation unit and are not referenced from the outside
(e.g. the auto test cases).

It's this stripping I would like to circumvent, so I need to somehow
reference the BOOST_AUTO_TEST_CASE from outside the translation unit,
or use some other trick.  I was wondering if you knew how to do that.

Cheers,

Pierre

On 4/12/06, Gennadiy Rozental <[hidden email]> wrote:

> >I would like to use the BOOST_AUTO_TEST_CASE() facility in a static
> > library.  Obviously this library does not have a main() so it needs to
> > be linked with a test executable which may run test cases found in one
> > or more of those static libraries.
> >
> > Unfortunately, the tests do not make it past the linker.  The
> > executable links fine but runs none of the tests defined in the
> > libraries.  Could it be that BOOST_AUTO_TEST_CASE() works via some
> > global which gets stripped when the static lib is created?
> >
> > Do you have a suggestion for a workaround?  The idea is to keep some
> > of the lowest-level unit test code in the same translation unit as the
> > class implementation.
>
> Unfortunately I don't think it could work this way. Both your library and
> final executable link with Boost.Test statically. You end up with 2 version
> of Boost.Test runtime and which one is in use is the matter of linker
> implementation. What you could do though is build dynamic library and link
> with dynamic version of Boost.Test (cvs already support that). This
> configuration is tested and work as expected.
>
> Gennadiy
>
>
>
> _______________________________________________
> Boost-users mailing list
> [hidden email]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: link issues with BOOST_AUTO_TEST_CASE() facility

Gennadiy Rozental

"Pierre-Jules Tremblay" <[hidden email]> wrote in message
news:[hidden email]...

> Hmmm... I don't understand.  What do you mean by "static lib linking
> Boost.Test statically" ?
>
> To my knowledge, the linker does attempt to resolve symbols referenced
> BY static libraries, it only does so for dlls and executables.  It
> can, however, strip from the static library bits of code which are
> local to a translation unit and are not referenced from the outside
> (e.g. the auto test cases).
>
> It's this stripping I would like to circumvent, so I need to somehow
> reference the BOOST_AUTO_TEST_CASE from outside the translation unit,
> or use some other trick.  I was wondering if you knew how to do that.

Hmm. You probably right. Anyway: try to use dynamic build. I've made sure
this configuration works.

Gennadiy



_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users