[Test] boost_unit_test_framework and main()
I'm having trouble getting programs using boost_unit_test_framework to link. The fundamental issue is that trying to link something like this: g++ -fPIC -o algorithms_test algorithms_test.o - lboost_unit_test_framework dies with a linker error: /usr/bin/ld: Undefined symbols: _main collect2: ld returned 1 exit status The issue, of course, is that "main" lives within the library boost_unit_test_framework, but linkers don't look into libraries (either static or dynamic) to find main. I suspect this is also the reason for the FAQ item on the test library page (http:// www.boost.org/libs/test/doc/faq.html#Item_9), which says that Boost Test components cannot be compiled as DLL, but perhaps there are other issues there. Our tests pass because BBv2 decides to put the archive file on the link line: g++ -fPIC -o algorithms_test algorithms_test.o libboost_unit_test_framework.a For some reason, this non-standard practice seems to work... but I can't imagine it's truly portable, and it forces users of boost_unit_test_framework into statically linking in a non- traditional way. Why must main() be in a library? It seems a trivial matter to fix. - Doug
Douglas Gregor wrote:
I'm having trouble getting programs using boost_unit_test_framework to link. The fundamental issue is that trying to link something like this:
g++ -fPIC -o algorithms_test algorithms_test.o - lboost_unit_test_framework
dies with a linker error:
/usr/bin/ld: Undefined symbols: _main collect2: ld returned 1 exit status
The issue, of course, is that "main" lives within the library boost_unit_test_framework, but linkers don't look into libraries (either static or dynamic) to find main.
I think this is false, see below.
Our tests pass because BBv2 decides to put the archive file on the link line:
g++ -fPIC -o algorithms_test algorithms_test.o libboost_unit_test_framework.a
For some reason, this non-standard practice seems to work... but I can't imagine it's truly portable,
It's absolutely portable.
and it forces users of boost_unit_test_framework into statically linking in a non- traditional way.
The above statements all seem to be false. There's no difference, in my testing, between libfoo.a and -L . -lfoo provided the latter finds the same libfoo.a. Further, in my testing putting 'main' in static library works. I believe that even works on Windows. Furthermore, previous testing reveals that on Linux, putting 'main' in shared library works as well. You can easily test it for yourself.
Why must main() be in a library? It seems a trivial matter to fix.
The real issue is that there's no 'main()' in library, as shown below: ghost@wind:~/Work/Boost/boost-rc/stage/lib$ readelf --symbols libboost_unit_test_framework-gcc40-d.so | grep main 871: 00074a43 17 OBJECT WEAK DEFAULT 12 _ZTSSt12domain_error 1253: 0007ed68 12 OBJECT WEAK DEFAULT 22 _ZTISt12domain_error 165: 00000000 0 FILE LOCAL DEFAULT ABS unit_test_main.cpp 259: 0007ed98 4 OBJECT LOCAL HIDDEN 22 DW.ref._ZTISt12domain_err 1128: 00074a43 17 OBJECT WEAK DEFAULT 12 _ZTSSt12domain_error 1510: 0007ed68 12 OBJECT WEAK DEFAULT 22 _ZTISt12domain_error When both static and shared libraries are present, gcc picks shared on most platforms of note. Since shared library lacks 'main', you get linker error. I believe this is intentional change made in Boost.Test for 1.34, in the interest of making Linux (where 'main' can be in shared library) and Windows (where 'main' cannot be in shared library), uniform. However, you'd need to ask Gennadiy how to your tests work now. - Volodya
Hi ! An'n Dingsdag 15 Mai 2007 hett Vladimir Prus schreven:
Douglas Gregor wrote:
Our tests pass because BBv2 decides to put the archive file on the link line:
g++ -fPIC -o algorithms_test algorithms_test.o libboost_unit_test_framework.a
No, it uses the static library, which has _main.
Further, in my testing putting 'main' in static library works. I believe that even works on Windows. Furthermore, previous testing reveals that on Linux, putting 'main' in shared library works as well.
Correct.
Why must main() be in a library? It seems a trivial matter to fix. The real issue is that there's no 'main()' in library, as shown below:
ghost@wind:~/Work/Boost/boost-rc/stage/lib$ readelf --symbols libboost_unit_test_framework-gcc40-d.so | grep main 871: 00074a43 17 OBJECT WEAK DEFAULT 12 _ZTSSt12domain_error 1253: 0007ed68 12 OBJECT WEAK DEFAULT 22 _ZTISt12domain_error 165: 00000000 0 FILE LOCAL DEFAULT ABS unit_test_main.cpp 259: 0007ed98 4 OBJECT LOCAL HIDDEN 22 DW.ref._ZTISt12domain_err 1128: 00074a43 17 OBJECT WEAK DEFAULT 12 _ZTSSt12domain_error 1510: 0007ed68 12 OBJECT WEAK DEFAULT 22 _ZTISt12domain_error
When both static and shared libraries are present, gcc picks shared on most platforms of note. Since shared library lacks 'main', you get linker error.
Right.
I believe this is intentional change made in Boost.Test for 1.34, in the interest of making Linux (where 'main' can be in shared library) and Windows (where 'main' cannot be in shared library), uniform.
Yes, that was the intention
However, you'd need to ask Gennadiy how to your tests work now.
Just #define BOOST_TEST_DYN_LINK The autotest code then creates a main for you. 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 ;-)) Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
On Tue, 15 May 2007 11:33:42 +0200 Jürgen Hunold <juergen.hunold@ivembh.de> wrote:
Just #define BOOST_TEST_DYN_LINK
The autotest code then creates a main for you.
I have the same problems. I did include -DBOOST_TEST_DYN_LINK in the compilation, but I still get the error. I see a vague reference in the documentation. So, specifically, what is the TRUE, and REASONABLE way of getting all my previous test programs to link correctly with 1.34?
"Jody Hagins" <jody-boost-011304@atdesk.com> wrote in message news:20070515090224.2a0760c4.jody-boost-011304@atdesk.com... On Tue, 15 May 2007 11:33:42 +0200 Jürgen Hunold <juergen.hunold@ivembh.de> wrote:
Just #define BOOST_TEST_DYN_LINK The autotest code then creates a main for you.
I have the same problems. I did include -DBOOST_TEST_DYN_LINK in the compilation, but I still get the error.
Please provide an example where it fails if you use dynamic library variant and define above flag. Gennadiy
On May 15, 2007, at 3:33 AM, Jürgen Hunold wrote:
An'n Dingsdag 15 Mai 2007 hett Vladimir Prus schreven:
I believe this is intentional change made in Boost.Test for 1.34, in the interest of making Linux (where 'main' can be in shared library) and Windows (where 'main' cannot be in shared library), uniform.
Yes, that was the intention
I understand the reasoning---uniformity of behavior across platforms---but I believe this change was a mistake. My rationale follows. When linking on Windows, if both a DLL and a static library are available, which one does the linker choose?
However, you'd need to ask Gennadiy how to your tests work now.
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 line g++ mytest.cpp -I $BOOST_HDRDIR -L $BOOST_ROOT/lib - lboost_unit_test_framework-gcc33-mt-d 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. 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. We've already had some user confusion on this change, e.g., http://lists.boost.org/boost-users/2007/05/27716.php 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. - Doug
Douglas Gregor wrote:
On May 15, 2007, at 3:33 AM, Jürgen Hunold wrote:
An'n Dingsdag 15 Mai 2007 hett Vladimir Prus schreven:
I believe this is intentional change made in Boost.Test for 1.34, in the interest of making Linux (where 'main' can be in shared library) and Windows (where 'main' cannot be in shared library), uniform.
Yes, that was the intention
I understand the reasoning---uniformity of behavior across platforms---but I believe this change was a mistake. My rationale follows.
When linking on Windows, if both a DLL and a static library are available, which one does the linker choose?
Such situation is impossible on Windows, as you cannot link to DLL directly, and you cannot have both static lib and import lib have the same name. That said, I don't know what point you was trying to make, so I don't know if my clarification changes that point ;-) And finally, since this does not appear to be a Boost.Build issue whatsoever, I'm going to let you and Gennadiy sort it out. - Volodya
On May 15, 2007, at 7:41 AM, Vladimir Prus wrote:
Douglas Gregor wrote:
I understand the reasoning---uniformity of behavior across platforms---but I believe this change was a mistake. My rationale follows.
When linking on Windows, if both a DLL and a static library are available, which one does the linker choose?
Such situation is impossible on Windows, as you cannot link to DLL directly, and you cannot have both static lib and import lib have the same name.
That said, I don't know what point you was trying to make, so I don't know if my clarification changes that point ;-)
I wasn't sure I had a point, but I think I do :) The point is that the change to keep main() out of shared libraries on *nix, which was motivated by uniformity with Windows, doesn't really make things uniform. It exacerbates the difference between the *nix model---where shared and static can coincide with the same name, and the linker prefers the shared one---and the Windows model---where shared and static must live in separate places, making the user explicitly choose which kind of linking to perform.
And finally, since this does not appear to be a Boost.Build issue whatsoever, I'm going to let you and Gennadiy sort it out.
Nope, not a Boost.Build issue at all. Sorry about the noise! - Doug
"Douglas Gregor" <doug.gregor@gmail.com> wrote in message news:AA5497DC-33CA-4CEC-9F65-257CE7A0589F@osl.iu.edu...
The point is that the change to keep main() out of shared libraries on *nix, which was motivated by uniformity with Windows, doesn't really make things uniform. It exacerbates the difference between the *nix model---where shared and static can coincide with the same name,
This is Boost.Build library decision and not platform feature. Also all *nix compilers I know provides the way to specify whcih variant you want to use.
and the linker prefers the shared one---and the Windows model---where shared and static must live in separate places, making the user explicitly choose which kind of linking to perform.
And finally, since this does not appear to be a Boost.Build issue whatsoever, I'm going to let you and Gennadiy sort it out.
Nope, not a Boost.Build issue at all. Sorry about the noise!
It is. Kind of. Though not nesseserily Gennadiy
On Tue, 15 May 2007 07:33:39 -0600 Douglas Gregor <doug.gregor@gmail.com> wrote:
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.
We were able to "work around" this problem by moving the dynamic library out of the way, so the linker only picked up the static library. It worked with just the -L/-l nomenclature, and did not require a specific listing of the static library. This brings up an issue that impacts the build environment. This is a "different" approach from the norm, but hear me out... The boost libraries already have lots of decorations. Why not add an extra decoration, like '-z' to static libraries so that users can easily decide if they want the dynamic library or the static library. My current project naming does that, and it is very easy for an application to specify some static and some dynamic libs with having to fuss with -static and -dynamic, which you may not be able to control in "deep" build systems (where the link line is automatically built for you based on what you request. To keep the "default" *nix behavior, we decorate the staatic library, and do not decorate the dynamic one...
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.
I agree. Worse, our tests that now pass on 1.33 fail to build on 1.34. They require extra stuff in the code to work on 1.34... not the worst thing in the world, but... here's the kicker... we have to change every single test program we have to accomodate these changes... We now need to define BOOST_TEST_DYN_LINK in the appropriate build files We now have to define BOOST_TEST_MAIN in all our test programs that used to get main() by simply linking to the shared library. That's a LOT of source files to change. In summary, I have to change EVERY SINGLE test program in my company that uses Boost.Test and does not use auto-test (though I probably need to change those as well, because that feature is deprecated... though still supported)... and EVERY SINGLE makefile that builds them. Yes, a semi-smart shell script can probably make most of these changes. However, it's a bit annoying to change our tests for every boost release. I've been a staunch supporter of Boost.Test in the past. Right now, I'm getting it with both barrels from fellow employees who are having to change everything to support 1.34. Just yesterday, one of them argued that we have had to make major changes to our tests with every single boost release since 1.29. He argued that we should stop using it and use a different test framework. I argued that I like Boost.Test, it works for us, and the tests are easy to write. He said he would rather spend more time with a more cumbersome tool than have to fix tests everytime we want to use a new version of Boost. He also said that the drastic changes are not documented very well, and he has suffered enough. I am finding it more difficult to argue my side...
"Jody Hagins" <jody-boost-011304@atdesk.com> wrote in message news:20070515103839.0b5109ee.jody-boost-011304@atdesk.com...
On Tue, 15 May 2007 07:33:39 -0600 Douglas Gregor <doug.gregor@gmail.com> wrote:
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.
I agree. Worse, our tests that now pass on 1.33 fail to build on 1.34. They require extra stuff in the code to work on 1.34... not the worst thing in the world, but... here's the kicker... we have to change every single test program we have to accomodate these changes...
We now need to define BOOST_TEST_DYN_LINK in the appropriate build files
Only if you use dynamic version of the UTF. But this is common requirements of all boost libraries.
We now have to define BOOST_TEST_MAIN in all our test programs that used to get main() by simply linking to the shared library. That's a LOT of source files to change.
That's not true. Or rather mostly not true. If you used to use static library and continue using it no change required. If you used shared library variants and had BOOST_TEST_AUTO_MAIN no change required either. If you used dynamic library and did not define above flag you have much bigger problem. you test module won't compile at all. The initialization function signature is changed.
In summary, I have to change EVERY SINGLE test program in my company that uses Boost.Test and does not use auto-test (though I probably need to change those as well, because that feature is deprecated... though still supported)... and EVERY SINGLE makefile that builds them.
What do you mean? Automatic registration facilities are not only still supported in a scope thay were defined in 1.33.1, but in fact significantly improved and extended. I personally recommend moving all your test modules to this facilties. As for the test modules that employ manual registraition and static library variant, my understanding is that they worked my chance. You "thought" you are linking with static library, while in fact you linked with shared one. The only change is required for test modules that employ manual registration and dynamic library variant. 1.34.0 allows you now to build these on NT without any code change. But you are required to make it conformant with new initalization function specification and implement function main() manually. I am showing example of how it's done on my Friday session. HTH, Gennadiy
On Wed, 16 May 2007 02:41:08 -0400 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
We now need to define BOOST_TEST_DYN_LINK in the appropriate build files
Only if you use dynamic version of the UTF. But this is common requirements of all boost libraries.
Odd, then, that we've been using many parts of boost for years, and this is the first time we've encountered this "common requirement." We are not doing anything special in this case, and the sad part is that our existing tests break. Again, I reiterate, it is NOT a good thing that we have to rewrite our tests just to see if our code works with the latest release of boost.
We now have to define BOOST_TEST_MAIN in all our test programs that used to get main() by simply linking to the shared library. That's a LOT of source files to change.
That's not true. Or rather mostly not true. If you used to use static library and continue using it no change required. If you used shared library
Our tests link against the shared library, since that's what you get by default on *nix systems. The change breaks all existing tests.
variants and had BOOST_TEST_AUTO_MAIN no change required either. If you used
Not true. According to the old documentation, we used BOOST_TEST_AUTO_MAIN only in the cases where we were using AUTO_TEST, which we had to change to BOOST_TEST_CASE (or some similar incantation -- deprecated previously, and removed now -- no real argument there except the lack of documentation with the release). However, all our tests that use the framework instead of auto-tests have to change.
dynamic library and did not define above flag you have much bigger problem. you test module won't compile at all. The initialization function signature is changed.
Hmmm. I have not experienced the problem you specify. We used BOOST_TEST_AUTO_MAIN for the tests that used the auto-test features, and did not use it for tests that were not auto-tests... for those, we simply defined our own test_main or whatever it is called.
In summary, I have to change EVERY SINGLE test program in my company that uses Boost.Test and does not use auto-test (though I probably need to change those as well, because that feature is deprecated... though still supported)... and EVERY SINGLE makefile that builds them.
What do you mean? Automatic registration facilities are not only still
supported in a scope thay were defined in 1.33.1, but in fact significantly improved and extended. I personally recommend moving all your test modules to this facilties. As for the test modules that employ manual registraition and static library variant, my understanding is that they worked my chance.
I do not understand the above paragaph.
You "thought" you are linking with static library, while in fact you linked
No, I've been developing on *nix systems for over 25 years. I actually built the ELF support for an SVr4 variant years ago. I *knew* I was linking with the dynamic library. That's what I expected, and it is what I got. I have a bunch of tests, and linking them all with the static library uses a lot of extra disk space. I DO NOT want to link with the static library. For me, there are only two reasons I want to link with a static library, and neither of them revolves around the notion that a function lives in the static lib but not the dynamic lib.
with shared one. The only change is required for test modules that employ manual registration and dynamic library variant. 1.34.0 allows you now to build these on NT without any code change. But you are required to make it conformant with new initalization function specification and implement function main() manually. I am showing example of how it's done on my Friday session.
Again, I must be missing something. Most of our tests conform to one of two models. Auto-tests, which look like this (prior to necessary code changes to conform with 1.34)... #define BOOST_AUTO_TEST_MAIN #include <boost/test/auto_unit_test.hpp> // A number of tests, similar to this BOOST_AUTO_UNIT_TEST(default_normalize_test) { // ... } For these tests, we had to change BOOST_AUTO_UNIT_TEST to BOOST_TEST_CASE, and then we got linker errors. We then had to add -DBOOST_TEST_DYN_LINK to the makefiles. Our other variant (which is much more popular) is this pattern... #include "boost/test/unit_test.hpp" // A bunch of test code test_suite * init_unit_test_suite(int, char * []) { test_suite * ts = BOOST_TEST_SUITE("simple_format_ut"); // A number of test_suite method calls return ts; } For all of these tests, we had to add #define BOOST_TEST_MAIN to each file (well, we could not add it to all files, we had to pick one that would be the "main" and add it there because we link several files into one test executable). We also had to add the -DBOOST_TEST_DYN_LINK flag in the compiler line. Personally, I think this is a terrible solution. I am not a windows person, so I'm not sure what other options exist. I understand putting link-time stuff into a compile of object files that are going into a shared library. However, it makes no sense for executables. I like running my final tests of my own code with both dynamic and shared libraries. This way, I know I didn't build one wrongly. Using Boost.Test, however, I now have to compile different variants depending on whether I want to link with a static library or a shared library. To me, that is wrong and unacceptable... aside from the fact that it breaks my existing tests. Let me restate that... I have come to accept the fact that our tests are going to change with almost every release of boost. My colleagues have not accepted it... mostly because they have to do most of the work, and I don't. However, the whole concept of compiling code based on linking with a static or dynamic library is just plain wrong. If you are trying for consistency, then I'd be more in favor of removing main() completely from the libraries than requiring different compilation flags depending on how it would be linked.
"Jody Hagins" <jody-boost-011304@atdesk.com> wrote in message news:20070516092500.59f0ebd0.jody-boost-011304@atdesk.com...
On Wed, 16 May 2007 02:41:08 -0400 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
We now need to define BOOST_TEST_DYN_LINK in the appropriate build files
Only if you use dynamic version of the UTF. But this is common requirements of all boost libraries.
Odd, then, that we've been using many parts of boost for years, and this is the first time we've encountered this "common requirement." We are not doing anything special in this case, and the sad part is that our existing tests break.
BOOST_ALL_DYN_LINK or BOOST_<lib>_DYN_LINK are required for dynamic library compilation of any library. It worked on *nix machines before cause it happends thhat there is no difference in usage semantic for both variants.
Again, I reiterate, it is NOT a good thing that we have to rewrite our tests just to see if our code works with the latest release of boost.
I don't believe you have to.
We now have to define BOOST_TEST_MAIN in all our test programs that used to get main() by simply linking to the shared library. That's a LOT of source files to change.
That's not true. Or rather mostly not true. If you used to use static library and continue using it no change required. If you used shared library
Our tests link against the shared library, since that's what you get by default on *nix systems. The change breaks all existing tests.
Boost.Test by default is configured to be used with static library variant. To use dynamic library variant you need to define above flag.
variants and had BOOST_TEST_AUTO_MAIN no change required either. If you used
Not true. According to the old documentation, we used BOOST_TEST_AUTO_MAIN only in the cases where we were using AUTO_TEST, which we had to change to BOOST_TEST_CASE (or some similar incantation
BOOST_AUTO_TEST_CASE
-- deprecated previously, and removed now -- no real argument there except the lack of documentation with the release).
I did not get from above. Why do you say "Not True"? Do you mean that your test modules linked with dynamic library variant and BOOST_AUTO_TEST_CASE fails. It shouldn't. Did you define BOOST_TEST_DYN_LINK somewhere in your make file?
However, all our tests that use the framework instead of auto-tests have to change.
Yes. Or you could switch to static library variant and make no changes.
dynamic library and did not define above flag you have much bigger problem. you test module won't compile at all. The initialization function signature is changed.
Hmmm. I have not experienced the problem you specify. We used BOOST_TEST_AUTO_MAIN for the tests that used the auto-test features, and did not use it for tests that were not auto-tests... for those, we simply defined our own test_main or whatever it is called.
That's because you did not define BOOST_TEST_DYN_LINK.
In summary, I have to change EVERY SINGLE test program in my company that uses Boost.Test and does not use auto-test (though I probably need to change those as well, because that feature is deprecated... though still supported)... and EVERY SINGLE makefile that builds them.
What do you mean? Automatic registration facilities are not only still
supported in a scope thay were defined in 1.33.1, but in fact significantly improved and extended. I personally recommend moving all your test modules to this facilties. As for the test modules that employ manual registraition and static library variant, my understanding is that they worked my chance.
I do not understand the above paragaph.
My point is that "the feature is depricated" statement is not correct. Auto-registration facilities are live and well. Even better than before.
You "thought" you are linking with static library, while in fact you linked
No, I've been developing on *nix systems for over 25 years. I actually built the ELF support for an SVr4 variant years ago. I *knew* I was linking with the dynamic library. That's what I expected, and it is what I got. I have a bunch of tests, and linking them all with the static library uses a lot of extra disk space. I DO NOT want to link with the static library.
For me, there are only two reasons I want to link with a static library, and neither of them revolves around the notion that a function lives in the static lib but not the dynamic lib.
In a short term you may opt to use static library variant for the test modules that are using manual registration. If you do insist on using dynamic library the change is an order. Here is an example from my presentation: #define BOOST_TEST_DYN_LINK #include <boost/test/unit_test.hpp> #include <boost/bind.hpp> using namespace boost::unit_test; void free_test_function( int i, int j ) { BOOST_CHECK( true /* test assertion */ ); } bool init_function() { framework::master_test_suite(). add( BOOST_TEST_CASE( boost::bind( &free_test_function, 1, 1 ) ) ); framework::master_test_suite(). add( BOOST_TEST_CASE( boost::bind( &free_test_function, 1, 2 ) ) ); framework::master_test_suite(). add( BOOST_TEST_CASE( boost::bind( &free_test_function, 2, 1 ) ) ); return true; } int main( int argc, char* argv[] ) { return ::boost::unit_test::unit_test_main( &init_function, argc, argv ); }
with shared one. The only change is required for test modules that employ manual registration and dynamic library variant. 1.34.0 allows you now to build these on NT without any code change. But you are required to make it conformant with new initalization function specification and implement function main() manually. I am showing example of how it's done on my Friday session.
Again, I must be missing something. Most of our tests conform to one of two models. Auto-tests, which look like this (prior to necessary code changes to conform with 1.34)...
#define BOOST_AUTO_TEST_MAIN #include <boost/test/auto_unit_test.hpp>
// A number of tests, similar to this BOOST_AUTO_UNIT_TEST(default_normalize_test) { // ... }
For these tests, we had to change BOOST_AUTO_UNIT_TEST to BOOST_TEST_CASE, and then we got linker errors. We then had to add -DBOOST_TEST_DYN_LINK to the makefiles.
And it starter to work, yes?
Our other variant (which is much more popular) is this pattern...
#include "boost/test/unit_test.hpp"
// A bunch of test code
test_suite * init_unit_test_suite(int, char * []) { test_suite * ts = BOOST_TEST_SUITE("simple_format_ut"); // A number of test_suite method calls return ts; }
For all of these tests, we had to add #define BOOST_TEST_MAIN to each
This is plain wrong. BOOST_TEST_MAIN has nothing to do with test modules that employ manual registration.
file (well, we could not add it to all files, we had to pick one that would be the "main" and add it there because we link several files into one test executable). We also had to add the -DBOOST_TEST_DYN_LINK flag in the compiler line.
And you should see an error indicating that there is no function main()
Personally, I think this is a terrible solution. I am not a windows person, so I'm not sure what other options exist. I understand putting link-time stuff into a compile of object files that are going into a shared library. However, it makes no sense for executables. I like running my final tests of my own code with both dynamic and shared libraries. This way, I know I didn't build one wrongly. Using Boost.Test, however, I now have to compile different variants depending on whether I want to link with a static library or a shared library. To me, that is wrong and unacceptable... aside from the fact that it breaks my existing tests.
Do you know any other way to make dynamic library work portably?
Let me restate that... I have come to accept the fact that our tests are going to change with almost every release of boost. My colleagues have not accepted it... mostly because they have to do most of the work, and I don't. However, the whole concept of compiling code based on linking with a static or dynamic library is just plain wrong.
I dont expect any breaking changes any more. The reason this was changes is because dynamiclibrary support was broken and half baked.
If you are trying for consistency, then I'd be more in favor of removing main() completely from the libraries than requiring different compilation flags depending on how it would be linked.
I considerred this option. But this would require users of static library and manual registraition (and they are majority for now from what I understand) to implement function main() explicetly similar to an example above. I did make an effort to minimize an impact. If you use automated registration (which you should try to anyway, there very small number of cases where you cant) the new dynamic library support works without any changes. Gennadiy
On Wed, 16 May 2007 11:14:26 -0400 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
"Jody Hagins" <jody-boost-011304@atdesk.com> wrote in message news:20070516092500.59f0ebd0.jody-boost-011304@atdesk.com...
On Wed, 16 May 2007 02:41:08 -0400 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
We now need to define BOOST_TEST_DYN_LINK in the appropriate build > > files
Only if you use dynamic version of the UTF. But this is common requirements of all boost libraries.
Odd, then, that we've been using many parts of boost for years, and this is the first time we've encountered this "common requirement." We are not doing anything special in this case, and the sad part is that our existing tests break.
BOOST_ALL_DYN_LINK or BOOST_<lib>_DYN_LINK are required for dynamic library compilation of any library. It worked on *nix machines before cause it happends thhat there is no difference in usage semantic for both variants.
Maybe I'm missing something... I am not compiling a library... I am compiling an application that simply uses a library. Why do I have to specify in the compiler flags, how that object file will be linked, when that decision is made at link time. I have *never* used a library where my application code had to be compiled differently depending on whether I planned to link against a static or dynamic version of the same library. That just does not make any sense to me.
Again, I reiterate, it is NOT a good thing that we have to rewrite our tests just to see if our code works with the latest release of boost.
I don't believe you have to.
Well, your belief and my reality do not coincide ;-) I have already given you examples of existing tests that compiled, linked, and ran fine with 1.33.1. Simply changing to 1.34 results in tests that do not build. We had to make a number of changes (again, previously listed) to get them working.
Boost.Test by default is configured to be used with static library variant. To use dynamic library variant you need to define above flag.
Why does there have to be a difference? Aren't the 1.34 changes supposed to creare more harmony? Instead, they have now caused *nix users to jump through crazy hoops that they never had to do before. That's the main thing that bothers me.
I did not get from above. Why do you say "Not True"? Do you mean that your test modules linked with dynamic library variant and BOOST_AUTO_TEST_CASE fails. It shouldn't. Did you define BOOST_TEST_DYN_LINK somewhere in your make file?
Because your statement was not true, at least according to my understanding of "truth." Let me try to restate... All our tests previously linked with the shared library. Some tests were what I call auto-tests. They no longer link because main() was removed from the shared library. I had to change the makefile so that the tests were compiled with a LINKER flag. After making that change, they built and ran. My argument is not that the tests do not run after making the changes... it is that I SHOULD NOT HAVE TO MAKE THE CHANGES. And, if there are changes to be made, it is wrong to have the shared and static use cases so different. I understand on windows there is a huge issue with shared/static libraries. Fine. I don't have to deal with that. Why do *nix users now have to worry about dynamic/shared issues they never had to deal with before? I understand you are trying to make the library more consistent for users of multiple platforms. I can appreciate that. however, your changes have simply made them very odd and unconventional for *nix users.
Yes. Or you could switch to static library variant and make no changes.
Which means a change to makefiles also... and it also means you have to static link all tests. Tests should be run as both static and dynamic linked to ensure both libs are tested. Also, as mainline development, I only want tests compiled against shared libs. The linking is much faster, and the space is far less. For final testing, tests are built agains static and dynamic libs.
That's because you did not define BOOST_TEST_DYN_LINK.
I feel like I beating the same drum. I never had to define that macro before. Now, to get my auto-tests to properly link, I have to define it when the test modules are compiled. Compiling application source files based on how they will be linked is unacceptable to me.
My point is that "the feature is depricated" statement is not correct.
Auto-registration facilities are live and well. Even better than before.
OK... but that blasted BOOST_TEST_DYN_LINK is now required, when I've never had to use it for anything before. You said this is a common boost practice. What is it used for then, besides building shared libraries, or doing something on windows?
In a short term you may opt to use static library variant for the test
modules that are using manual registration. If you do insist on using dynamic library the change is an order. Here is an example from my
Right. Unfortunately, most of our tests were written using the manual registration. I don't remember back that far, but I imagine the auto-registration either didn't work as we thought, or was not available in 1.29, or we were simply unaware of it. In any event, we have a ton of tests written that way.
For these tests, we had to change BOOST_AUTO_UNIT_TEST to BOOST_TEST_CASE, and then we got linker errors. We then had to add -DBOOST_TEST_DYN_LINK to the makefiles.
And it starter to work, yes?
Yes, that's correct.
This is plain wrong. BOOST_TEST_MAIN has nothing to do with test modules that employ manual registration.
Hmmm. That's what we did, and it "worked." We couldn't find anything telling us how it should be done, so we tried that, and it seemed to work.
Do you know any other way to make dynamic library work portably?
Since I'm not an expert at windows DLLs, I have to answer NO.
I dont expect any breaking changes any more. The reason this was changes is because dynamiclibrary support was broken and half baked.
I can accept that. I can even accept that we need to change our tests. What I can not accept is the implementation of the solution.
If you are trying for consistency, then I'd be more in favor of removing main() completely from the libraries than requiring different compilation flags depending on how it would be linked.
I considerred this option. But this would require users of static library and manual registraition (and they are majority for now from what I understand) to implement function main() explicetly similar to an example above. I did make an effort to minimize an impact. If you use automated registration (which you should try to anyway, there very small number of cases where you cant) the new dynamic library support works without any changes.
We have to add the DYN_LINK command to auto-tests, and we have lots of manual registration tests, and the solution is anything but benign. I'd MUCH rather see it either fully contained in both liraries (like before), or completely gone from both libraries. In my opinion, half baked or not, the previous solution worked. The current soultion, where you have to compile differently whether you use the static or dynamic library is the half baked one...
"Jody Hagins" <jody-boost-011304@atdesk.com> wrote in message news:20070516130359.399372bc.jody-boost-011304@atdesk.com...
On Wed, 16 May 2007 11:14:26 -0400 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
"Jody Hagins" <jody-boost-011304@atdesk.com> wrote in message news:20070516092500.59f0ebd0.jody-boost-011304@atdesk.com...
On Wed, 16 May 2007 02:41:08 -0400 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
We now need to define BOOST_TEST_DYN_LINK in the appropriate build > > files
Only if you use dynamic version of the UTF. But this is common requirements of all boost libraries.
Odd, then, that we've been using many parts of boost for years, and this is the first time we've encountered this "common requirement." We are not doing anything special in this case, and the sad part is that our existing tests break.
BOOST_ALL_DYN_LINK or BOOST_<lib>_DYN_LINK are required for dynamic library compilation of any library. It worked on *nix machines before cause it happends thhat there is no difference in usage semantic for both variants.
Maybe I'm missing something... I am not compiling a library... I am compiling an application that simply uses a library. Why do I have to specify in the compiler flags, how that object file will be linked, when that decision is made at link time. I have *never* used a library where
Becasue it's a requirement of portable development. These flags exist for every library that employs standalone compilation.
my application code had to be compiled differently depending on whether I planned to link against a static or dynamic version of the same library. That just does not make any sense to me.
I got lucky and don't have to worry about 8nix/NT portability. But this is not the case for many others. But i am open to your proposition how address these portabiltiy issues differently.
Again, I reiterate, it is NOT a good thing that we have to rewrite our tests just to see if our code works with the latest release of boost.
I don't believe you have to.
Well, your belief and my reality do not coincide ;-) I have already given you examples of existing tests that compiled, linked, and ran fine with 1.33.1. Simply changing to 1.34 results in tests that do not build. We had to make a number of changes (again, previously listed) to get them working.
Now I must be missing something. If you prefer to avoid any code changes all you need to do is for the test modules that employ automated registration define BOOST_TEST_DYN_LINK in makefile (which you should have done in a first place anyway). And for the test modules that employ manual registration make sure in makefiles that they link with static library instead. You can do this either by changing library name or adding -static flags somewhere in command line. Now all your test modules should work fine.
Boost.Test by default is configured to be used with static library variant. To use dynamic library variant you need to define above flag.
Why does there have to be a difference? Aren't the 1.34 changes supposed to creare more harmony? Instead, they have now caused *nix users to jump through crazy hoops that they never had to do before. That's the main thing that bothers me.
What from above sugestion you call "crazy hoops"?
I did not get from above. Why do you say "Not True"? Do you mean that your test modules linked with dynamic library variant and BOOST_AUTO_TEST_CASE fails. It shouldn't. Did you define BOOST_TEST_DYN_LINK somewhere in your make file?
Because your statement was not true, at least according to my understanding of "truth."
Which statement? There were several. One was "automated facilities are not removed, but more powerfull"
Let me try to restate... All our tests previously linked with the shared library. Some tests were what I call auto-tests. They no longer link because main() was removed from the shared library. I had to change the makefile so that the tests were compiled with a LINKER flag. After making that change, they built and ran.
Ok. And flag like this is required by any boost library for portable linkage with dynamic library.
My argument is not that the tests do not run after making the changes... it is that I SHOULD NOT HAVE TO MAKE THE CHANGES. And, if there are changes to be made, it is wrong to have the shared and static use cases so different.
My argument is that due to lack of propoer docs (which is totally my fault) you misused this configuration previosly. It happends to show up with next release, which started to make use of some of the expected dofferences.
I understand on windows there is a huge issue with shared/static libraries. Fine. I don't have to deal with that. Why do *nix users now have to worry about dynamic/shared issues they never had to deal with before? I understand you are trying to make the library more consistent for users of multiple platforms. I can appreciate that. however, your changes have simply made them very odd and unconventional for *nix users.
Yes. The change was driven by portability considerations. As for "odd and unconventional" it's matter of opinion. You don't ususally jump from static to dynamic library all the time. Consider this a UTF requirement if you opted to use shared library, you need to comply to particular init function interfacess and implement function main() manually. Did you see an example in previos post? Do you think the interface is "odd and unconventional"?
Yes. Or you could switch to static library variant and make no changes.
Which means a change to makefiles also... and it also means you have to static link all tests. Tests should be run as both static and dynamic linked to ensure both libs are tested.
Why? Are you testing UTF or your own code? Stick to one variant that works best for you and use it.
Also, as mainline development, I only want tests compiled against shared libs. The linking is much faster, and the space is far less. For final testing, tests are built agains static and dynamic libs.
If you goal to use shared library you can move to it incrementally. Switch test modules that employ manual registration to static libs for now. Later on you either switch to automated registration (which is direction you should strive to go) or start using proper interfaces required by dynamic library variant.
That's because you did not define BOOST_TEST_DYN_LINK.
I feel like I beating the same drum. I never had to define that macro before. Now, to get my auto-tests to properly link, I have to define it when the test modules are compiled. Compiling application source files based on how they will be linked is unacceptable to me.
This is a reality of portable development. if you see diferent options lets hear it. Usually it's not a problem at all. You stick to one variant and use it everywhere.
My point is that "the feature is depricated" statement is not correct.
Auto-registration facilities are live and well. Even better than before.
OK... but that blasted BOOST_TEST_DYN_LINK is now required, when I've never had to use it for anything before.
You said this is a common boost practice. What is it used for then, besides building shared libraries, or doing something on windows?
Read "standalone library compilation guidelines".
This is plain wrong. BOOST_TEST_MAIN has nothing to do with test modules that employ manual registration.
Hmmm. That's what we did, and it "worked." We couldn't find anything telling us how it should be done, so we tried that, and it seemed to work.
Show me an example. BOOST_TEST_MAIN causes empty init function generation, which should obviosly interfere with your own one.
I dont expect any breaking changes any more. The reason this was changes is because dynamiclibrary support was broken and half baked.
I can accept that. I can even accept that we need to change our tests. What I can not accept is the implementation of the solution.
What specifically you don;t like in dynamic library variant implementation?
I'd MUCH rather see it either fully contained in both liraries (like before), or completely gone from both libraries.
The UTF is trying to be as helpfull as possible. For static library variant it's possible to put function main() inside the library. And the UTF does that. For dynamic library variant you can't do this portably. But UTF tries to automatically generate function main() in case if you are using automated facilties. Otherwise it's your reponsibility. The problem the way I see it is that you for some reason trying to test the same test module using both static and dynamic variant. I personally do not see any reason to do this, unleess you are testing how the UTF itself works. Gennadiy
Hi Jody, Stick to your guns! Boost Test is one of the better C++ testing frameworks out there. Anyway, what I did (in 1.33.1 - hope it still works in 1.34!) was I built a little static library with a cpp file that defined BOOST_AUTO_TEST_MAIN (or whatever it is) and #included the right file: // file: something.cpp #define BOOST_AUTO_TEST_MAIN #include <boost/test/auto/main.hpp> // or whatever it is Then all my tests are linked with this little library and also the unit test library. If you are using a semi-sane build system, you should be able to attach this little library to the link line for all your tests. Good luck, Sohail -----Original Message----- From: boost-bounces@lists.boost.org on behalf of Jody Hagins Sent: Tue 5/15/2007 7:38 AM To: boost@lists.boost.org Subject: Re: [boost] [Test] boost_unit_test_framework and main() We now need to define BOOST_TEST_DYN_LINK in the appropriate build files We now have to define BOOST_TEST_MAIN in all our test programs that used to get main() by simply linking to the shared library. That's a LOT of source files to change. In summary, I have to change EVERY SINGLE test program in my company that uses Boost.Test and does not use auto-test (though I probably need to change those as well, because that feature is deprecated... though still supported)... and EVERY SINGLE makefile that builds them.
On Wed, 16 May 2007 05:57:58 -0700 "Sohail Somani" <s.somani@fincad.com> wrote:
Hi Jody,
Stick to your guns! Boost Test is one of the better C++ testing frameworks out there.
I *really* do like it, and have defended it on this list a number of times.
Anyway, what I did (in 1.33.1 - hope it still works in 1.34!) was I built a little static library with a cpp file that defined BOOST_AUTO_TEST_MAIN (or whatever it is) and #included the right file:
// file: something.cpp #define BOOST_AUTO_TEST_MAIN #include <boost/test/auto/main.hpp> // or whatever it is
Then all my tests are linked with this little library and also the unit test library. If you are using a semi-sane build system, you should be able to attach this little library to the link line for all your tests.
That's not a bad idea. However, for 1.34, you will probably have to at least make the DYN_LINK change. I really think I'd rather have main be ansent from all the libraries, rather than in some and absent from others.
Well I use the static version of Boost Test :D -----Original Message----- From: boost-bounces@lists.boost.org on behalf of Jody Hagins Sent: Wed 5/16/2007 7:06 AM To: boost@lists.boost.org Subject: Re: [boost] [Test] boost_unit_test_framework and main() That's not a bad idea. However, for 1.34, you will probably have to at least make the DYN_LINK change.
"Douglas Gregor" <doug.gregor@gmail.com> wrote in message news:9F43FA00-A732-4471-B7EA-794F928E690E@osl.iu.edu... 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 line
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 - lboost_unit_test_framework-gcc33-mt-d
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 update. I plan to talk about different usage variants on friday. Also we may discusse this during the break if you up to it. Gennadiy
on Tue May 15 2007, Douglas Gregor <doug.gregor-AT-gmail.com> wrote:
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 line
g++ mytest.cpp -I $BOOST_HDRDIR -L $BOOST_ROOT/lib - lboost_unit_test_framework-gcc33-mt-d
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. 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.
(3) It's what the getting started guide tells users to do. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:871whgeltf.fsf@grogan.peloton...
on Tue May 15 2007, Douglas Gregor <doug.gregor-AT-gmail.com> wrote:
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 line
g++ mytest.cpp -I $BOOST_HDRDIR -L $BOOST_ROOT/lib - lboost_unit_test_framework-gcc33-mt-d
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. 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.
(3) It's what the getting started guide tells users to do.
And it will work for trivial test presented by the user: #define BOOST_TEST_MAIN #define BOOST_TEST_DYN_LINK #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE(mytest) { } with a single change to add one define BOOST_TEST_DYN_LINK or in original version #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE(mytest) { } if we somehow make Boost.Build to produce different names for static and dynamic libraries. Gennadiy
On Thu, 17 May 2007 15:52:13 -0400 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
And it will work for trivial test presented by the user:
#define BOOST_TEST_MAIN #define BOOST_TEST_DYN_LINK #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE(mytest) { }
OK. I'm obviously missing something. Where in the boost documentation does it say that I should be compiling code with the DYN_LINK flags if I am NOT building a library? I'd really like to read that rationale, because it simply makes no sense to me. I understand the "BOOST_TEST_MAIN" but the BOOST_TEST_DYN_LINK does not make sense. The link decision is totally independent of the compilation UNLESS the code is being built to be included in a library. This is obviously not the case here, as an executable, not a library, is being built. You reference this in your previous reply to me (I'll reply to that one tomorrow, from work), but I can not find that documentation. Maybe a bit more specific about where I can find it, please.
"Jody Hagins" <jody-boost-011304@atdesk.com> wrote in message news:20070517205434.4a311d0e.jody-boost-011304@atdesk.com...
On Thu, 17 May 2007 15:52:13 -0400 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
And it will work for trivial test presented by the user:
#define BOOST_TEST_MAIN #define BOOST_TEST_DYN_LINK #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE(mytest) { }
OK. I'm obviously missing something. Where in the boost documentation does it say that I should be compiling code with the DYN_LINK flags if I am NOT building a library?
I'd really like to read that rationale, because it simply makes no sense to me.
I understand the "BOOST_TEST_MAIN" but the BOOST_TEST_DYN_LINK does not make sense. The link decision is totally independent of the compilation UNLESS the code is being built to be included in a library. This is obviously not the case here, as an executable, not a library, is being built.
This is not true for NT, ergo it's not true in general.
You reference this in your previous reply to me (I'll reply to that one tomorrow, from work), but I can not find that documentation. Maybe a bit more specific about where I can find it, please.
http://www.boost.org/boost/config/user.hpp http://www.boost.org/more/separate_compilation.html Gennadiy
On Sat, 19 May 2007 23:02:44 -0400 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
I understand the "BOOST_TEST_MAIN" but the BOOST_TEST_DYN_LINK does not make sense. The link decision is totally independent of the compilation UNLESS the code is being built to be included in a library. This is obviously not the case here, as an executable, not a library, is being built.
This is not true for NT, ergo it's not true in general.
I'll take your word for it... I don't develop for NT. Which begs the issue... why do I now have to conform to a workaround for NT... I've never had to do it before, and if certain systems require workarounds, then they should be transparent to others. Developers that are USING a library should be insulated from stuff required for other platforms as much as possible. Since everything worked previous to 1.34 without this "NT workaround" it is obviously possible... so my point is, whay did it have to change? It looks, to me, that it was a choice, not a necessity. For *nix users, this is completely strange, unconventional behavior, not pushed upon them... where before 1.34 they did not even have to worry about it. Again, I'll say... the decision does not make sense to me.
"Jody Hagins" <jody-boost-011304@atdesk.com> wrote in message news:20070520104928.342b913e.jody-boost-011304@atdesk.com...
On Sat, 19 May 2007 23:02:44 -0400 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
I understand the "BOOST_TEST_MAIN" but the BOOST_TEST_DYN_LINK does not make sense. The link decision is totally independent of the compilation UNLESS the code is being built to be included in a library. This is obviously not the case here, as an executable, not a library, is being built.
This is not true for NT, ergo it's not true in general.
I'll take your word for it... I don't develop for NT. Which begs the issue... why do I now have to conform to a workaround for NT... I've never had to do it before, and if certain systems require workarounds, then they should be transparent to others.
Developers that are USING a library should be insulated from stuff required for other platforms as much as possible. Since everything worked previous to 1.34 without this "NT workaround" it is obviously possible... so my point is, whay did it have to change? It looks, to me, that it was a choice, not a necessity.
For *nix users, this is completely strange, unconventional behavior, not pushed upon them... where before 1.34 they did not even have to worry about it. Again, I'll say... the decision does not make sense to me.
Let me repeat that for a portable development you sometimes are required to do things that are not natural for one particular platform. That said, let's now try to find some way to make you happy ;) I can create a separate target that builds shared library using static library flags. This target will only exist for !NT platforms. Now we just need to decide how to name these 3 targets. From what I see in Jamfile.v2 this new target will have to be named differently from two built now. That means that static and this "like static" shared library will be named differently. Let me know what you think. Gennadiy
Jody Hagins writes:
#define BOOST_TEST_MAIN #define BOOST_TEST_DYN_LINK #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE(mytest) { }
OK. I'm obviously missing something. Where in the boost documentation does it say that I should be compiling code with the DYN_LINK flags if I am NOT building a library?
From the front page of the "Boost Test Library" documentation, follow these links:
Components --> Program Execution Monitor --> Compilation There it is. It doesn't feel like that page is particularly easy to find, though. Maybe there should be a "Building Instructions" link on the index page? I doubt many users would look into a section called "Components" to figure out how to link Boost.Test to their programs. Peter
On May 15, 2007, at 12:32 AM, Vladimir Prus wrote:
\and it forces users of boost_unit_test_framework into statically linking in a non- traditional way.
The above statements all seem to be false. There's no difference, in my testing, between
libfoo.a
and
-L . -lfoo
provided the latter finds the same libfoo.a.
Further, in my testing putting 'main' in static library works. I believe that even works on Windows. Furthermore, previous testing reveals that on Linux, putting 'main' in shared library works as well.
You can easily test it for yourself.
Hah! I just realized that I was picking up the shared library (from / usr/lib) rather than the static library I expected. D'oh! Thanks for setting me straight on this.
Why must main() be in a library? It seems a trivial matter to fix.
The real issue is that there's no 'main()' in library, as shown below:
No main() in the shared library, but it's in the static library. - Doug
participants (8)
-
David Abrahams -
Douglas Gregor -
Gennadiy Rozental -
Jody Hagins -
Jürgen Hunold -
Peter Simons -
Sohail Somani -
Vladimir Prus