[Test][Thread] Regression since 9 December?

Vicente J. Botet Escriba

11 Jan 2015 11 Jan '15

9:59 a.m.

Hi, I'm getting a regression on all the Boost.Thread tests using Boost.Test to fail after this commit https://github.com/boostorg/test/commit/1eaffb96ceec82882a4e947c99735a37271c.... See http://www.boost.org/development/tests/develop/developer/output/Sandia-clang.... |../../../boost/system/config.hpp:34:3: erreur: #error Must not define both BOOST_SYSTEM_DYN_LINK and BOOST_SYSTEM_STATIC_LINK # error Must not define both BOOST_SYSTEM_DYN_LINK and BOOST_SYSTEM_STATIC_LINK | When I comment the added lines everything works correctly as before. The Boost.Thread jamfile contains | <library>/boost/test//boost_unit_test_framework/<link>static | If I change it to | <library>/boost/test//boost_unit_test_framework | I get an error |darwin.link ../../../bin.v2/libs/thread/test/test_thread.test/darwin-4.9.1/debug/threading-multi/test_thread Undefined symbols for architecture x86_64: "_main", referenced from: start in crt1.10.6.o ld: symbol(s) not found for architecture x86_64 collect2: erreur: ld a retourné 1 code d'état d'exécution "/usr/gcc-4.9.1/bin/g++-4.9.1" -o "../../../bin.v2/libs/thread/test/test_thread.test/darwin-4.9.1/debug/threading-multi/test_thread" "../../../bin.v2/libs/thread/test/test_thread.test/darwin-4.9.1/debug/threading-multi/test_thread.o" "../../../bin.v2/libs/thread/test/test_thread.test/darwin-4.9.1/debug/threading-multi/winrt_init.o" "../../../bin.v2/libs/test/build/darwin-4.9.1/debug/threading-multi/libboost_unit_test_framework.dylib" "../../../bin.v2/libs/timer/build/darwin-4.9.1/debug/threading-multi/libboost_timer.dylib" "../../../bin.v2/libs/chrono/build/darwin-4.9.1/debug/threading-multi/libboost_chrono.dylib" "../../../bin.v2/libs/thread/build/darwin-4.9.1/debug/threading-multi/libboost_thread.dylib" "../../../bin.v2/libs/system/build/darwin-4.9.1/debug/threading-multi/libboost_system.dylib" -g | Do others observe the same? Do you have an idea how this can be fixed? Best, Vicente

Show replies by date

Vicente J. Botet Escriba

11 Jan 11 Jan

11:58 p.m.

Le 11/01/15 10:59, Vicente J. Botet Escriba a écrit :

...

Hi,

I'm getting a regression on all the Boost.Thread tests using Boost.Test to fail after this commit https://github.com/boostorg/test/commit/1eaffb96ceec82882a4e947c99735a37271c.... See http://www.boost.org/development/tests/develop/developer/output/Sandia-clang....

|../../../boost/system/config.hpp:34:3: erreur: #error Must not define both BOOST_SYSTEM_DYN_LINK and BOOST_SYSTEM_STATIC_LINK # error Must not define both BOOST_SYSTEM_DYN_LINK and BOOST_SYSTEM_STATIC_LINK |

When I comment the added lines everything works correctly as before.

The Boost.Thread jamfile contains

| <library>/boost/test//boost_unit_test_framework/<link>static |

If I change it to

| <library>/boost/test//boost_unit_test_framework |

I get an error

|darwin.link ../../../bin.v2/libs/thread/test/test_thread.test/darwin-4.9.1/debug/threading-multi/test_thread Undefined symbols for architecture x86_64: "_main", referenced from: start in crt1.10.6.o ld: symbol(s) not found for architecture x86_64 collect2: erreur: ld a retourné 1 code d'état d'exécution

"/usr/gcc-4.9.1/bin/g++-4.9.1" -o "../../../bin.v2/libs/thread/test/test_thread.test/darwin-4.9.1/debug/threading-multi/test_thread" "../../../bin.v2/libs/thread/test/test_thread.test/darwin-4.9.1/debug/threading-multi/test_thread.o" "../../../bin.v2/libs/thread/test/test_thread.test/darwin-4.9.1/debug/threading-multi/winrt_init.o" "../../../bin.v2/libs/test/build/darwin-4.9.1/debug/threading-multi/libboost_unit_test_framework.dylib" "../../../bin.v2/libs/timer/build/darwin-4.9.1/debug/threading-multi/libboost_timer.dylib" "../../../bin.v2/libs/chrono/build/darwin-4.9.1/debug/threading-multi/libboost_chrono.dylib" "../../../bin.v2/libs/thread/build/darwin-4.9.1/debug/threading-multi/libboost_thread.dylib" "../../../bin.v2/libs/system/build/darwin-4.9.1/debug/threading-multi/libboost_system.dylib" -g |

Do others observe the same?

Do you have an idea how this can be fixed?

With the help of one of the Boost.Test maintainers, I have reached to fix the issues. Boost.Thread was requesting to link static while Boost.Time didn't. What is surprising is that moving to a shared link has needed to modify all the sources :( Best, Vicente

Adam Wulkiewicz

12 Jan 12 Jan

4:22 p.m.

Vicente J. Botet Escriba wrote:

...

Le 11/01/15 10:59, Vicente J. Botet Escriba a écrit :

...
Hi,

I'm getting a regression on all the Boost.Thread tests using Boost.Test to fail after this commit https://github.com/boostorg/test/commit/1eaffb96ceec82882a4e947c99735a37271c.... See http://www.boost.org/development/tests/develop/developer/output/Sandia-clang....

<snip>

...
Do you have an idea how this can be fixed?

With the help of one of the Boost.Test maintainers, I have reached to fix the issues. Boost.Thread was requesting to link static while Boost.Time didn't.

Does this change caused undefined reference linker errors (symbols from System, Test, Chrono) in regression tests for the latest runs? http://www.boost.org/development/tests/develop/developer/output/Sandia-gcc-4... http://www.boost.org/development/tests/develop/developer/output/Sandia-gcc-4... http://www.boost.org/development/tests/develop/developer/output/Sandia-gcc-4... http://www.boost.org/development/tests/develop/developer/output/Sandia-gcc-4... http://www.boost.org/development/tests/develop/developer/output/Sandia-gcc-4... http://www.boost.org/development/tests/develop/developer/output/Sandia-gcc-4... If the answer was yes, then should the Jamfiles be somehow modified? Regards, Adam

Vicente J. Botet Escriba

5:15 p.m.

Le 12/01/15 17:22, Adam Wulkiewicz a écrit :

...

Vicente J. Botet Escriba wrote:

...
Le 11/01/15 10:59, Vicente J. Botet Escriba a écrit :

...
Hi,

I'm getting a regression on all the Boost.Thread tests using Boost.Test to fail after this commit

<snip>

...
Do you have an idea how this can be fixed?

With the help of one of the Boost.Test maintainers, I have reached to fix the issues. Boost.Thread was requesting to link static while Boost.Time didn't.

Does this change caused undefined reference linker errors (symbols from System, Test, Chrono) in regression tests for the latest runs?

No that I'm aware of.

...

If the answer was yes, then should the Jamfiles be somehow modified?

I have changed just the Boost.Thread libs/thread/test/Jamfile and a lot of tests files that didn't worked linking in shared more with Boost.Test. I don't know why, but with the current changes everything seems ok. Best, Vicente

Raffi Enficiaud

7:49 p.m.

Adam Wulkiewicz writes:

...

Vicente J. Botet Escriba wrote:

...
Le 11/01/15 10:59, Vicente J. Botet Escriba a écrit :

...
Hi, ... Do you have an idea how this can be fixed?

With the help of one of the Boost.Test maintainers, I have reached to fix the issues. Boost.Thread was requesting to link static while Boost.Time didn't.

Does this change caused undefined reference linker errors (symbols from System, Test, Chrono) in regression tests for the latest runs?

http://www.boost.org/development/tests/develop/developer/output/Sandia-gcc-4...

...

...

...

If the answer was yes, then should the Jamfiles be somehow modified?

Hi, No the problem generated a compile-time failure as, by the chain of dependencies, it turned out that static and dynamic link to boost.system was requested. The faulty part was an explicit link to the static version of boost.test in the jamfile while compiling the shared variant. Since both boost.thread and boost.test depend on chrono (boost.thread directly and boost.test through timer), it ended up to a clash for the shared variant tests of boost.thread. See https://github.com/boostorg/test/commit/1eaffb96ceec82882a4e947c99735a37271c... and https://github.com/boostorg/thread/pull/38 for further information and also for the explanation of why the source files should be changed.

...

Regards, Adam

Best, Raffi

Adam Wulkiewicz

11:29 p.m.

Hi Raffi, Raffi Enficiaud wrote:

...

No the problem generated a compile-time failure as, by the chain of dependencies, it turned out that static and dynamic link to boost.system was requested. The faulty part was an explicit link to the static version of boost.test in the jamfile while compiling the shared variant. Since both boost.thread and boost.test depend on chrono (boost.thread directly and boost.test through timer), it ended up to a clash for the shared variant tests of boost.thread.

See https://github.com/boostorg/test/commit/1eaffb96ceec82882a4e947c99735a37271c... and https://github.com/boostorg/thread/pull/38

for further information and also for the explanation of why the source files should be changed.

In Boost.Geometry we doesn't use Thread or dynamically linked Test. In most of the tests only the following headers are included: # include # include # include plus test_main() defined. AFAIU it's not required to link against Test in this case. To be honest I'm not sure why this was ok in the past. Is Test static lib automatically built by bjam if e.g. import testing ; is found in a Jamfile? And in the past Timer was built automatically with Test but this commit have changed it https://github.com/boostorg/test/commit/fa6f4f34bed04e938b4020df51918c776b77... ? Anyway, how do you suggest libraries authors should modify the tests? What should be the best practice for tests using minimal/header-only Test. Should we just specify <library>/boost/timer//boost_timer or is there some more preferable way? Regards, Adam

Raffi Enficiaud

13 Jan 13 Jan

12:27 a.m.

Adam Wulkiewicz writes:

...

Hi Raffi,

<snip>

In Boost.Geometry we doesn't use Thread or dynamically linked Test. In most of the tests only the following headers are included: # include # include # include plus test_main() defined. AFAIU it's not required to link against Test in this case.

Then I would say the only thing you need is to add boost.timer as a dependency, but this should be done by boost.test in fact (see below). The problem of boost.thread was mainly caused by building against both shared and static boost.test with the same sources. In geometry apparently you are using the execution monitor (eg. geometry/test/algorithms/append.cpp) and the header-only variant of boost.test (eg. geometry/test/algorithms/distance/distance_areal_areal.cpp). So the problem looks like being the link against boost.timer only.

...

To be honest I'm not sure why this was ok in the past. Is Test static lib automatically built by bjam if e.g. import testing ; is found in a Jamfile?

I am very very far from being an expert of Jamfile. If you use the boost.test with static link, I think "<library>/boost/test//boost_unit_test_framework/<link>static" in the requirements is enough for building it. I do not know if this is done by "import testing".

...

And in the past Timer was built automatically with Test but this commit have changed it

https://github.com/boostorg/test/commit/fa6f4f34bed04e938b4020df51918c776b77...

...

?

Right, I rolled it back. I erroneously thought boost.timer being a header only library. Apparently this worked fine on darwin.

...

Anyway, how do you suggest libraries authors should modify the tests? What should be the best practice for tests using minimal/header-only Test. Should we just specify <library>/boost/timer//boost_timer or is there some more preferable way?

For symbols of boost.timer missing, I would say "do nothing" as it should be handled by boost.test. Please bug me (offline if you prefer) once you have the test results.

...

Regards, Adam

Best, Raffi

Adam Wulkiewicz

1:18 a.m.

Raffi Enficiaud wrote:

...

Adam Wulkiewicz writes:

...
To be honest I'm not sure why this was ok in the past. Is Test static lib automatically built by bjam if e.g. import testing ; is found in a Jamfile? I am very very far from being an expert of Jamfile. If you use the boost.test with static link, I think "<library>/boost/test//boost_unit_test_framework/<link>static" in the requirements is enough for building it. I do not know if this is done by "import testing".

FYI, on my machine when I run the tests bjam passes the following parameters into the compiler: -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_CHRONO_THREAD_DISABLED -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_TIMER_DYN_LINK=1

...

...
And in the past Timer was built automatically with Test but this commit have changed it

https://github.com/boostorg/test/commit/fa6f4f34bed04e938b4020df51918c776b77...

...
? Right, I rolled it back. I erroneously thought boost.timer being a header only library. Apparently this worked fine on darwin. I already fixed it by linking Timer manually. But ok, if it was possible to find a solution which works without forcing the maintainers to modify the tests it should probably be prefered.

...

...
Anyway, how do you suggest libraries authors should modify the tests? What should be the best practice for tests using minimal/header-only Test. Should we just specify <library>/boost/timer//boost_timer or is there some more preferable way? For symbols of boost.timer missing, I would say "do nothing" as it should be handled by boost.test. Please bug me (offline if you prefer) once you have the test results.

(below [BOOST_ROOT] is a path to Boost) In the previous version (<use>/boost/timer//boost_timer) both <library>/boost/test//boost_unit_test_framework/<link>static and <library>/boost/timer//boost_timer in the requirements fixed the issue. And I was forced to modify only the top-most Jamfile so it was't a big change. Btw on MSVC12 defining: <library>/boost/test//boost_unit_test_framework/ without <link>static caused a lot warnings like: [BOOST_ROOT]\boost/test/impl/debug.ipp(634) : warning C4273: 'boost::debug::under_debugger' : inconsistent dll linkage [BOOST_ROOT]\boost/test/debug.hpp(54) : see previous definition of 'under_debugger' and errors similar to: [BOOST_ROOT]\boost/test/impl/test_tools.ipp(394) : error C2491: 'boost::test_tools::tt_detail::prod_report_format' : definition of dllimport function not allowed So after your switch in Test's build/Jamfile to <link>/boost/timer//boost_timer testing doesn't work anymore. Bjam fails with the following error: [BOOST_ROOT]/tools/build/src/build\project.jam:711: in class@project-attributes.set from module object(project-attributes)@1762 error: usage-requirements <define>BOOST_TEST_NO_AUTO_LINK=1 <link>shared,<toolset>msvc:<cxxflags>-wd4275 <link>/boost/timer//boost_timer have non-free properties <link>/boost/timer//boost_timer [BOOST_ROOT]/tools/build/src/build\project.jam:1054: in project from module project-rules ..\..\libs\test\build\Jamfile.v2:33: in modules.load from module Jamfile<[BOOST_ROOT]\libs\test\build> I think that to get this you should probably have a clean setup (e.g. bin.v2 directory removed). Regards, Adam

Adam Wulkiewicz

14 Jan 14 Jan

1:27 p.m.

Hi Raffi, Raffi Enficiaud wrote:

...

Adam Wulkiewicz writes:

...
And in the past Timer was built automatically with Test but this commit have changed it

https://github.com/boostorg/test/commit/fa6f4f34bed04e938b4020df51918c776b77... Or maybe it was this change: https://github.com/boostorg/test/pull/15

...

...
? Right, I rolled it back. I erroneously thought boost.timer being a header only library. Apparently this worked fine on darwin.

...
Anyway, how do you suggest libraries authors should modify the tests? What should be the best practice for tests using minimal/header-only Test. Should we just specify <library>/boost/timer//boost_timer or is there some more preferable way? For symbols of boost.timer missing, I would say "do nothing" as it should be handled by boost.test. Please bug me (offline if you prefer) once you have the test results.

I saw that you tried to "fix" the issue in the latest commits to Test but it didn't help. It's still required to link against Timer or Test, see e.g. the failing Atomic tests vs the Geometry tests. So currently the usage of header-only version of Test probably has little sense. Or am I missing something? Regards, Adam

Jürgen Hunold

3:19 p.m.

Hi Adam, Am Mittwoch, 14. Januar 2015, 14:27:26 schrieb Adam Wulkiewicz:

...

Hi Raffi,

...

I saw that you tried to "fix" the issue in the latest commits to Test but it didn't help. It's still required to link against Timer or Test, see e.g. the failing Atomic tests vs the Geometry tests.

I've pushed a fix in https://github.com/boostorg/atomic/pull/4 This automatically pull in the dependency on Boost.Timer. This also works with the master version of Boost.Test, it can be merged to master before Boost.Test gets updated.

...

So currently the usage of header-only version of Test probably has little sense.

It still requieres linking against Boost.Timer. The correct solution would be to implement an optional header-only version of Boost.Timer. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

Andrey Semashev

4:47 p.m.

On Wed, Jan 14, 2015 at 6:19 PM, Jürgen Hunold wrote:

...

Hi Adam,

Am Mittwoch, 14. Januar 2015, 14:27:26 schrieb Adam Wulkiewicz:

...
Hi Raffi,

...
I saw that you tried to "fix" the issue in the latest commits to Test but it didn't help. It's still required to link against Timer or Test, see e.g. the failing Atomic tests vs the Geometry tests.

I've pushed a fix in https://github.com/boostorg/atomic/pull/4

This automatically pull in the dependency on Boost.Timer. This also works with the master version of Boost.Test, it can be merged to master before Boost.Test gets updated.

I commented in the pull request, but I'll post it here as well to gain more attention. Boost.Test explicitly provides a header-only version which previously did not require linking with any other libraries. Adding Boost.Timer as a link dependency looks like a bug to me and should be fixed in Boost.Test rather than in user libraries. I wonder when that dependency appeared and whether it can be reverted easily.

...

...
So currently the usage of header-only version of Test probably has little sense.

It still requieres linking against Boost.Timer.

Obviously, it was not the case not long ago.

Raffi Enficiaud

5:10 p.m.

Jürgen Hunold writes:

...

Hi Adam,

Am Mittwoch, 14. Januar 2015, 14:27:26 schrieb Adam Wulkiewicz:

...
Hi Raffi,

...
I saw that you tried to "fix" the issue in the latest commits to Test but it didn't help. It's still required to link against Timer or Test, see e.g. the failing Atomic tests vs the Geometry tests.

I've pushed a fix in https://github.com/boostorg/atomic/pull/4

Many thanks for helping fixing the mess.

...

This automatically pull in the dependency on Boost.Timer. This also works

with

...

the master version of Boost.Test, it can be merged to master before Boost.Test gets updated.

...
So currently the usage of header-only version of Test probably has little sense.

It still requieres linking against Boost.Timer. The correct solution would be to implement an optional header-only version of Boost.Timer.

+1 Initially I thought this was a header only library which also made us move from the old to the new API.

...

Yours,

Jürgen

Thank you Jürgen! Please also note that there is a clash in the new and old timer API: http://www.boost.org/development/tests/develop/developer/output/Sandia-clang... It is impossible to use the old and new API at the same time, as there is a namespace in the old API and a class in the new API with the same name. In boost.test we chose to use the new one and drop support for the old one. This was of course before we discovered that so many problem raised. I made the changes in boost.geometry, I am preparing a pull request for addressing these issues. Some other libraries also suffer from this apparently: - asio: looks like linking at the same time to shared and static version of system, might be generated by the changes in boost.test (I have to look further) - atomic: link missing - circular_buffer: link missing - lockfree: same as asio - numeric/ublas: link missing - pool: maybe the same as asio - tr1 : unclear what is happening here - regex: link missing - random: link missing The problems seen on geometry/extension do not seem to be produced by the changes in boost.test: http://www.boost.org/development/tests/develop/developer/geometry-extensions... BTW, it is hard to see the problems created by a range of commits. How to proceed? For instance, there are problems in boost.icl http://www.boost.org/development/tests/develop/developer/output/Sandia-clang... and I do not know if they were provoked by the changes in boost.test. Tests in geometry/test/robustness/overlay/linear_areal do not compile on my machine. Also there is an indirect inclusion of boost.timer from ./include/boost/geometry/algorithms/detail/overlay/assign_parents.hpp ./include/boost/geometry/algorithms/detail/overlay/overlay.hpp which produces a clash in the use of boost.timer.

Vicente J. Botet Escriba

7:35 p.m.

Le 14/01/15 18:10, Raffi Enficiaud a écrit :

...

Please also note that there is a clash in the new and old timer API:

http://www.boost.org/development/tests/develop/developer/output/Sandia-clang...

It is impossible to use the old and new API at the same time, as there is a namespace in the old API and a class in the new API with the same name. In boost.test we chose to use the new one and drop support for the old one. This was of course before we discovered that so many problem raised.

I made the changes in boost.geometry, I am preparing a pull request for addressing these issues. Some other libraries also suffer from this apparently: - asio: looks like linking at the same time to shared and static version of system, might be generated by the changes in boost.test (I have to look further) - atomic: link missing - circular_buffer: link missing - lockfree: same as asio - numeric/ublas: link missing - pool: maybe the same as asio - tr1 : unclear what is happening here - regex: link missing - random: link missing

The problems seen on geometry/extension do not seem to be produced by the changes in boost.test: http://www.boost.org/development/tests/develop/developer/geometry-extensions...

BTW, it is hard to see the problems created by a range of commits. How to proceed? For instance, there are problems in boost.icl http://www.boost.org/development/tests/develop/developer/output/Sandia-clang... and I do not know if they were provoked by the changes in boost.test.

Tests in geometry/test/robustness/overlay/linear_areal do not compile on my machine. Also there is an indirect inclusion of boost.timer from ./include/boost/geometry/algorithms/detail/overlay/assign_parents.hpp ./include/boost/geometry/algorithms/detail/overlay/overlay.hpp

which produces a clash in the use of boost.timer.

I suggest you to : * rollback your changes related to Boost.Timer, this should make all the libraries to work as before. * create a branch on which you move to the new Timer interface and you maybe need to link to (it would be preferable to don't need it). * Announce the breaking change on this ML (yes there is a breaking change if the user needs to link to Boost.Timer and didn't needed it before). * If the breaking change is accepted, propose PR for each one of the libraries :( I understand that this is more work than breaking all the users code, but at the end you will gain. HTH, Vicente P.S. I don't know what is the state of the Boost.Test develop branch, but if I were you (I'm not) I would follow the advice given by others in other threads: * Rename the develop branch to a feature branch. * Create a develop branch from the master branch. * Fix the major issues on the develop branch in parallel with the development of the new big feature. * When the feature is ready, merge it to develop and then to master.

Barend Gehrels

9:13 p.m.

New subject: [Test] Regression by using to Boost.Timer v2, Boost.Test is not header-only anymore

Hi, I changed the subject because it is not about Thread only. So as far as I understand, Boost.Test has moved from Boost.Timer v1 (2001) to Boost.Timer v2 (2011). Boost.Timer v2 depends on Boost.Chrono, which optionally can be compiled header-only, and on Boost.System. But Boost.Timer itself has no option to be compiled header-only (AFAIU). So basically the regression is in Boost.Timer, which now requires linking. But because that is already introduced in 2011, it cannot be called a sudden regression. However, the influence on Boost.Test is quite large. We use Boost.Test (the header-only option) since 2007 and wish to keep it header-only. I know what to do to make it compile (link with Boost.Timer) but that is an unwished option for several reasons, so: a regression. Rest of my answer below. Vicente J. Botet Escriba schreef op 14-1-2015 om 20:35:

...

Le 14/01/15 18:10, Raffi Enficiaud a écrit :

...
Please also note that there is a clash in the new and old timer API:

http://www.boost.org/development/tests/develop/developer/output/Sandia-clang...

It is impossible to use the old and new API at the same time, as there is a namespace in the old API and a class in the new API with the same name. In boost.test we chose to use the new one and drop support for the old one. This was of course before we discovered that so many problem raised.

I made the changes in boost.geometry, I am preparing a pull request for addressing these issues.

As discussed on github, I have noticed it. Thanks for the PR.

...

...
Some other libraries also suffer from this apparently: - asio: looks like linking at the same time to shared and static version of system, might be generated by the changes in boost.test (I have to look further) - atomic: link missing - circular_buffer: link missing - lockfree: same as asio - numeric/ublas: link missing - pool: maybe the same as asio - tr1 : unclear what is happening here - regex: link missing - random: link missing

The problems seen on geometry/extension do not seem to be produced by the changes in boost.test: http://www.boost.org/development/tests/develop/developer/geometry-extensions...

These are indeed unrelated to Boost.Test

...

...
BTW, it is hard to see the problems created by a range of commits. How to proceed? For instance, there are problems in boost.icl http://www.boost.org/development/tests/develop/developer/output/Sandia-clang...

and I do not know if they were provoked by the changes in boost.test.

Tests in geometry/test/robustness/overlay/linear_areal do not compile on my machine. Also there is an indirect inclusion of boost.timer from ./include/boost/geometry/algorithms/detail/overlay/assign_parents.hpp ./include/boost/geometry/algorithms/detail/overlay/overlay.hpp

which produces a clash in the use of boost.timer.

I suggest you to : * rollback your changes related to Boost.Timer, this should make all the libraries to work as before. * create a branch on which you move to the new Timer interface and you maybe need to link to (it would be preferable to don't need it). * Announce the breaking change on this ML (yes there is a breaking change if the user needs to link to Boost.Timer and didn't needed it before). * If the breaking change is accepted, propose PR for each one of the libraries :(

I understand that this is more work than breaking all the users code, but at the end you will gain.

HTH, Vicente

P.S. I don't know what is the state of the Boost.Test develop branch, but if I were you (I'm not) I would follow the advice given by others in other threads: * Rename the develop branch to a feature branch. * Create a develop branch from the master branch. * Fix the major issues on the develop branch in parallel with the development of the new big feature. * When the feature is ready, merge it to develop and then to master.

I agree with this recommended way of working. As mentioned above, the regression is due to Boost.Timer v2 which is incompatable with V1, and not header-only anymore. I understand the wish to advance to a new version of Boost.Timer. However, the problems should be solved. The first question I asked myself: why is Boost.Test timing anyway? It is doing regression tests and checking results, but should that be timed? It looks good to display the timings, but is it essential? So maybe it is an option to avoid the usage of Boost.Timer at all. Then I tried to solve my problems (all my projects do not work anymore because I don't use b2 but QtCreator projects, and I depend heavily on Boost.Test). I created a stub in test/utils/timer.hpp, avoiding the usage of Boost.Timer at all. See below for this adapted version, the essention is: with a define BOOST_TEST_DONT_USE_TIMER the complete Boost.Timer functionality is excluded, while all the rest of Boost.Test is still working. This solves my personal problems. 1) So that is suggestion one: create an option to avoid the usage of Boost.Timer, which solves all compatibility and linking problems. 2) If this is possible and the dependency is only in one file, it should be possible to use Boost.Chrono directly instead of Boost.Timer. Because Boost.Timer v2 is AFAIU a wrapper around Boost.Chrono, and Boost.Chrono is, conditionally, usable as header-only (according to the docs). So that is suggestion number two: use Boost.Chrono. 3) Suggestion three is that the regression in Boost.Timer, dated 2011, should be fixed. Why is it not possible to use Boost.Timer header-only? It was possible before! But that is probably not up to the Boost.Test team. OK - in the meantime I see the message which just comes in now, it is rolled-back. However, maybe you can do something with these suggestions. Regards, Barend // (C) Copyright Jamie Allsop 2015. // Distributed under the Boost Software License, Version 1.0. // (See accompanying file LICENSE_1_0.txt or copy at //http://www.boost.org/LICENSE_1_0.txt) // Seehttp://www.boost.org/libs/test for the library home page. // // Description : timer and elapsed types // *************************************************************************** #ifndef BOOST_TEST_UTILS_TIMER_HPP #define BOOST_TEST_UTILS_TIMER_HPP #if !defined(BOOST_TEST_DONT_USE_TIMER) #include #include #include <sstream> #endif namespace boost { namespace unit_test { // ************************************************************************** // // ************** opaque timer and elapsed types ************** // // ************************************************************************** // #if !defined(BOOST_TEST_DONT_USE_TIMER) typedef boost::timer::cpu_timer timer_t; typedef boost::timer::cpu_times elapsed_t; typedef boost::timer::nanosecond_type nanoseconds_t; inline long microsecond_cpu_time( elapsed_t elapsed ) { return ( elapsed.user + elapsed.system )/1000; } inline std::string deprecated_hrf_format( elapsed_t elapsed ) { std::ostringstream output; long duration = microsecond_cpu_time( elapsed ); if( duration % 1000 == 0 ) { output << duration/1000 << "ms"; } else { output << duration << "mks"; } return output.str(); } inline std::string to_string( elapsed_t elapsed ) { if( runtime_config::deprecated_timer_format() ) { return deprecated_hrf_format( elapsed ); } return boost::timer::format( elapsed, 9, "%ws wall, %us user + %ss system = %ts CPU (%p%)" ); } inline std::string to_xml( elapsed_t elapsed ) { std::ostringstream output; output << "<TestingTime>" << microsecond_cpu_time( elapsed ) << "</TestingTime>" << "<CpuTime>" << ( elapsed.user + elapsed.system ) << "</CpuTime>" << "<WallTime>" << elapsed.wall << "</WallTime>" << "<UserTime>" << elapsed.user << "</UserTime>" << "<SystemTime>" << elapsed.system << "</SystemTime>"; return output.str(); } inline bool has_time( const elapsed_t& elapsed ) { if( runtime_config::deprecated_timer_format() ) { return elapsed.user != 0 || elapsed.system != 0 ; } return elapsed.wall != 0 || elapsed.user != 0 || elapsed.system != 0; } #else typedef int elapsed_t; inline bool has_time( const elapsed_t& elapsed ) { return false; } inline std::string to_xml( elapsed_t elapsed ) { return ""; } inline std::string to_string( elapsed_t elapsed ) { return ""; } struct timer_t { void stop() {} elapsed_t elapsed() const { return 0; } }; #endif //____________________________________________________________________________// } // namespace unit_test } // namespace boost #endif // BOOST_TEST_UTILS_TIMER_HPP

Beman Dawes

15 Jan 15 Jan

8:08 p.m.

New subject: [Test] Regression by using to Boost.Timer v2, Boost.Test is not header-only anymore

On Wed, Jan 14, 2015 at 4:13 PM, Barend Gehrels wrote:

...

Hi,

I changed the subject because it is not about Thread only.

So as far as I understand, Boost.Test has moved from Boost.Timer v1 (2001) to Boost.Timer v2 (2011). Boost.Timer v2 depends on Boost.Chrono, which optionally can be compiled header-only, and on Boost.System. But Boost.Timer itself has no option to be compiled header-only (AFAIU). So basically the regression is in Boost.Timer, which now requires linking. But because that is already introduced in 2011, it cannot be called a sudden regression. However, the influence on Boost.Test is quite large.

We use Boost.Test (the header-only option) since 2007 and wish to keep it header-only. I know what to do to make it compile (link with Boost.Timer) but that is an unwished option for several reasons, so: a regression.

I looked a Boost.Timer, and it seems reasonable to add a header-only option. If you open a ticket, I'll give it a try. But it will be a week or two, so a ticket is best. Thanks, --Beman

Barend Gehrels

10:22 p.m.

New subject: [Test] Regression by using to Boost.Timer v2, Boost.Test is not header-only anymore

Hi Beman, Beman Dawes schreef op 15-1-2015 om 21:08:

...

On Wed, Jan 14, 2015 at 4:13 PM, Barend Gehrels wrote:

...
Hi,

I changed the subject because it is not about Thread only.

So as far as I understand, Boost.Test has moved from Boost.Timer v1 (2001) to Boost.Timer v2 (2011). Boost.Timer v2 depends on Boost.Chrono, which optionally can be compiled header-only, and on Boost.System. But Boost.Timer itself has no option to be compiled header-only (AFAIU). So basically the regression is in Boost.Timer, which now requires linking. But because that is already introduced in 2011, it cannot be called a sudden regression. However, the influence on Boost.Test is quite large.

We use Boost.Test (the header-only option) since 2007 and wish to keep it header-only. I know what to do to make it compile (link with Boost.Timer) but that is an unwished option for several reasons, so: a regression. I looked a Boost.Timer, and it seems reasonable to add a header-only option.

If you open a ticket, I'll give it a try. But it will be a week or two, so a ticket is best.

That is good news! Thanks. Ticket created: https://svn.boost.org/trac/boost/ticket/10935 Regards, Barend

Raffi Enficiaud

14 Jan 14 Jan

10:48 p.m.

Vicente J. Botet Escriba writes:

...

Le 14/01/15 18:10, Raffi Enficiaud a écrit :

...
I suggest you to : * rollback your changes related to Boost.Timer, this should make all the libraries to work as before.

done. I tested thread locally and it should work in its current state (no need to roll back anything).

...

* create a branch on which you move to the new Timer interface and you maybe need to link to (it would be preferable to don't need it). * Announce the breaking change on this ML (yes there is a breaking change if the user needs to link to Boost.Timer and didn't needed it before). * If the breaking change is accepted, propose PR for each one of the libraries :(

I understand that this is more work than breaking all the users code, but at the end you will gain.

well, I am not afraid of work, but since boost.timer new API depends on chrono, this change will not going to happen any time soon, as it breaks the “header only boost.test” contract. Also, breaking the code of others was, of course, not exactly the goal I was aiming for.

...

HTH, Vicente

P.S. I don't know what is the state of the Boost.Test develop branch, but if I were you (I'm not) I would follow the advice given by others in other threads: * Rename the develop branch to a feature branch. * Create a develop branch from the master branch. * Fix the major issues on the develop branch in parallel with the development of the new big feature. * When the feature is ready, merge it to develop and then to master.

The problem we encountered are not related to the way we are branching. OTOH creating a feature branch would not have tell us/me the problems encountered *before* the merge to develop/master. It is always possible to run the tests for the full boost locally, but this takes ages and for some reason some tests are getting stuck on my machine (I have to kill the processes manually). But I’m learning to use the tools provided by boost, and hopefully I will learn fast. Best, Raffi

Andrey Semashev

25 Jan 25 Jan

3:27 p.m.

On Wednesday 14 January 2015 22:48:24 Raffi Enficiaud wrote:

...

Vicente J. Botet Escriba writes:

...
Le 14/01/15 18:10, Raffi Enficiaud a écrit :

I suggest you to : * rollback your changes related to Boost.Timer, this should make all the libraries to work as before.

done. I tested thread locally and it should work in its current state (no need to roll back anything).

Something is still not right. Boost.Atomic tests are still failing: http://www.boost.org/development/tests/develop/developer/output/BP%20x86_64%... Were there other changes which removed main() definition from Boost.Test?

Andrey Semashev

3:57 p.m.

On Sunday 25 January 2015 18:27:28 you wrote:

...

On Wednesday 14 January 2015 22:48:24 Raffi Enficiaud wrote:

...
Vicente J. Botet Escriba writes:

...
Le 14/01/15 18:10, Raffi Enficiaud a écrit :

I suggest you to : * rollback your changes related to Boost.Timer, this should make all the libraries to work as before.

done. I tested thread locally and it should work in its current state (no need to roll back anything).

Something is still not right. Boost.Atomic tests are still failing:

http://www.boost.org/development/tests/develop/developer/output/BP%20x86_64% 20C++11-boost-bin-v2-libs-atomic-test-atomicity-test-clang-linux-3-5~c14_lib c++-debug-debug-symbols-off-threading-multi.html

Were there other changes which removed main() definition from Boost.Test?

Also, there were lots of warnings on MSVC like here: http://www.boost.org/development/tests/develop/developer/output/teeks99-08f-... Anyway, I decided to remove Boost.Test from Boost.Atomic tests.

Gennadiy Rozental

11:04 p.m.

Andrey Semashev writes:

...

Also, there were lots of warnings on MSVC like here:

http://www.boost.org/development/tests/develop/developer/output/teeks99- 08f-win2012R2-64on64-boost-bin-v2-libs-atomic-test-atomicity-test-msvc-14-0- debug-threading-multi.html

The same thing: "Error extracting file: No matching files were found." Are you sure are were looking at correct reports? I found these being updated pretty slowly.

...

Anyway, I decided to remove Boost.Test from Boost.Atomic tests.

You are free to do so, but just to make record strait: the issues in that case were caused by regression in Boost.Timer and minor misconfiguration in Boost.Thread. BTW I thought one of the main reason to move toward modular boost was the ability to build/test against master version of the dependencies. Why is this still not the case? Gennadiy

Andrey Semashev

26 Jan 26 Jan

7:33 a.m.

On Sunday 25 January 2015 23:04:44 Gennadiy Rozental wrote:

...

Andrey Semashev writes:

...
Also, there were lots of warnings on MSVC like here:

http://www.boost.org/development/tests/develop/developer/output/teeks99-> 08f-win2012R2-64on64-boost-bin-v2-libs-atomic-test-atomicity-test-msvc-14-0- debug-threading-multi.html

The same thing: "Error extracting file: No matching files were found."

Are you sure are were looking at correct reports? I found these being updated pretty slowly.

Same thing, the reports have been updated. Here are the warnings from another tester: call "c: \users\boost\appdata\local\temp\boost_regression\b2_msvc_12.0_vcvarsall_x86.cmd"

...

nul cl /Zm800 -nologo @"D: \local\teeks99-08\e\results\boost\bin.v2\libs\atomic\test\atomicity.test\msvc-12.0\debug\threading- multi\atomicity.obj.rsp"

atomicity.cpp D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(62) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::log_start' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(37) : see previous definition of 'log_start' D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(72) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::log_finish' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(38) : see previous definition of 'log_finish' D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(80) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::log_build_info' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(39) : see previous definition of 'log_build_info' D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(93) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::test_unit_start' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(41) : see previous definition of 'test_unit_start' D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(105) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::test_unit_finish' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(42) : see previous definition of 'test_unit_finish' D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(125) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::test_unit_skipped' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(43) : see previous definition of 'test_unit_skipped' D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(135) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::log_exception_start' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(45) : see previous definition of 'log_exception_start' D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(163) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::log_exception_finish' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(46) : see previous definition of 'log_exception_finish' D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(171) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::log_entry_start' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(48) : see previous definition of 'log_entry_start' D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(208) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::log_entry_value' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(49) : see previous definition of 'log_entry_value' D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(216) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::log_entry_value' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(50) : see previous definition of 'log_entry_value' D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(224) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::log_entry_finish' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(51) : see previous definition of 'log_entry_finish' D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(236) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::print_prefix' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(58) : see previous definition of 'print_prefix' D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(253) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::entry_context_start' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(53) : see previous definition of 'entry_context_start' D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(261) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::entry_context_finish' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(55) : see previous definition of 'entry_context_finish' D: \local\teeks99-08\e\boost_root\boost/test/impl/compiler_log_formatter.ipp(269) : warning C4273: 'boost::unit_test::output::compiler_log_formatter::log_entry_context' : inconsistent dll linkage D: \local\teeks99-08\e\boost_root\boost/test/output/compiler_log_formatter.hpp(54) : see previous definition of 'log_entry_context' ...and it goes on. http://www.boost.org/development/tests/develop/developer/output/teeks99-08e-...

...

...
Anyway, I decided to remove Boost.Test from Boost.Atomic tests.

You are free to do so, but just to make record strait: the issues in that case were caused by regression in Boost.Timer and minor misconfiguration in Boost.Thread.

At least Boost.Atomic tests were also affected, and there was a pull request fixing that. I can see a list of multiple affected libraries in this discussion.

...

BTW I thought one of the main reason to move toward modular boost was the ability to build/test against master version of the dependencies. Why is this still not the case?

Well, that's not me to ask, but personally I can see benefits of both approaches.

Raffi Enficiaud

9:27 a.m.

Andrey Semashev writes:

...

On Sunday 25 January 2015 23:04:44 Gennadiy Rozental wrote:

...
Andrey Semashev writes:

[snip]

...
...
Anyway, I decided to remove Boost.Test from Boost.Atomic tests.

You are free to do so, but just to make record strait: the issues in that case were caused by regression in Boost.Timer and minor misconfiguration in Boost.Thread.

At least Boost.Atomic tests were also affected, and there was a pull request fixing that. I can see a list of multiple affected libraries in this discussion.

If I understand correctly, the pull request that was merged (<use>/boost/test//boost_unit_test_framework) states only that the headers of boost.test are there when the tests of atomic are built. So this is just fixing the way now the modular boost works (the header having moved to libs/xxx/include/boost). So the impact on the link part should be null. I have a patch that fixes the issues you have with boost.test (it is just a matter of two lines to change). However, it would be good to understand why it worked and why this is not the case anymore. I had a closer look to the tests of boost.atomic: - the tests that are failing are using the test_execution_monitor in a include only (no linking) way. However, I went back through the documentation until boost 1.31 and I cannot see anywhere in the documentation such an interface to boost.test. These tests were added in 2012 if I am correct, and already using a non supported interface to boost.test. - it is hard to tell if those tests were not failing before the changes that were made and reverted. I compiled the boost.atomic tests by reverting boost.test back to c3ec41073f8385879721882373d39794c50791dd of *8 Nov 2012*, and the problem still occurs (version 427a757bbfba4118acb7e4b34dfb8f91dc121c28 of boost.atomic). So my guess is that something from the *environment* is causing these troubles, but the environment is a complex entity. So, if you are interested in this patch, I can send it to you. But several issues are raised concerning the modular boost workflow: - it is hard to tell, when we start a feature branch, what was caused by the modifications made in this feature branch. We can only see the status of the develop branch and the master branch. This is already good, but I think we have to think of a better way of testing modular boost. A possible solution is to test (on identified subset of workers) a feature branch against the state of boost right before the branch was created. This is to be jointly used with a "delta" of errors shown in the test report, because aiming at having the full boost green before branching is maybe something really hard to have, especially from the develop branch. But at least with this we can see what we are breaking before merging back to develop. - it would be nice I think to have for the test report the history, for at least something like 2 or 3 months. Then we would be able to see when a test started failing, which would ease a lot the identification of the source of the errors. - a nice thing would also to have the commit message from "Automated Commit " having the recap between the delta of revisions that are commited to the main boost. All these I think would ease the global workflow we have and addressing some issues we are facing: - feature branches are showing problems only when merged back to develop - identifications of the sources of the problems is kind of hard Best, Raffi Enficiaud

Andrey Semashev

9:49 a.m.

On Monday 26 January 2015 09:27:16 Raffi Enficiaud wrote:

...

If I understand correctly, the pull request that was merged (<use>/boost/test//boost_unit_test_framework) states only that the headers of boost.test are there when the tests of atomic are built. So this is just fixing the way now the modular boost works (the header having moved to libs/xxx/include/boost). So the impact on the link part should be null.

I have a patch that fixes the issues you have with boost.test (it is just a matter of two lines to change). However, it would be good to understand why it worked and why this is not the case anymore.

I had a closer look to the tests of boost.atomic:

- the tests that are failing are using the test_execution_monitor in a include only (no linking) way. However, I went back through the documentation until boost 1.31 and I cannot see anywhere in the documentation such an interface to boost.test. These tests were added in 2012 if I am correct, and already using a non supported interface to boost.test. - it is hard to tell if those tests were not failing before the changes that were made and reverted. I compiled the boost.atomic tests by reverting boost.test back to c3ec41073f8385879721882373d39794c50791dd of *8 Nov 2012*, and the problem still occurs (version 427a757bbfba4118acb7e4b34dfb8f91dc121c28 of boost.atomic). So my guess is that something from the *environment* is causing these troubles, but the environment is a complex entity.

Maybe. I really didn't dig too deep into this problem, I just remember that last time I made changes to Atomic (some time last summer, I think) the tests were green. It is possible that the tests broke at some point after I checked but before changes to Test or Timer when I wasn't constantly watching test results.

...

So, if you are interested in this patch, I can send it to you.

Thanks, but as I said I decided to switch away from Boost.Test. The switch is done and tests are turning green now. The point of my posts was mostly to let you know that something may still be wrong.

Gennadiy Rozental

25 Jan 25 Jan

10:57 p.m.

Andrey Semashev writes:

...

Something is still not right. Boost.Atomic tests are still failing:

http://www.boost.org/development/tests/develop/developer/output/BP%20x86_64%... 0C++11-boost-bin-v2-libs-atomic-test-atomicity-test-clang-linux-3- 5~c14_libc++-debug-debug-symbols-off-threading-multi.html I cannot open this link. It says there is some kind of error.

...

Were there other changes which removed main() definition from Boost.Test?

There were no changes in Boost.Test. All the changes that were done to upgrade to newer boost.timer were reverted. Gennadiy

Andrey Semashev

26 Jan 26 Jan

7:23 a.m.

On Sunday 25 January 2015 22:57:49 Gennadiy Rozental wrote:

...

Andrey Semashev writes:

...
Something is still not right. Boost.Atomic tests are still failing: http://www.boost.org/development/tests/develop/developer/output/BP%20x86_64% 2 0C++11-boost-bin-v2-libs-atomic-test-atomicity-test-clang-linux-3- 5~c14_libc++-debug-debug-symbols-off-threading-multi.html

I cannot open this link. It says there is some kind of error.

It seems some testers have cycled. Here is the report from another one that hasn't: Compile [2015-01-25 09:57:43 UTC]: succeed "clang++-3.4" -c -x c++ -Wno-c99-extensions -O0 -g -fno-inline -Wall -g - pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 - DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 - DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_TEST_DYN_LINK=1 - DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX - DBOOST_THREAD_USE_DLL=1 -DBOOST_TIMER_DYN_LINK=1 -I".." -o "/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/atomic/test/atomicity.test/clang- linux-3.4/debug/threading-multi/atomicity.o" "../libs/atomic/test/atomicity.cpp" Link [2015-01-25 09:57:43 UTC]: fail "clang++-3.4" -Wl,-R - Wl,"/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/atomic/build/clang- linux-3.4/debug/threading-multi" -Wl,-R - Wl,"/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/chrono/build/clang- linux-3.4/debug/threading-multi" -Wl,-R - Wl,"/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/system/build/clang- linux-3.4/debug/threading-multi" -Wl,-R - Wl,"/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/test/build/clang- linux-3.4/debug/threading-multi" -Wl,-R - Wl,"/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/thread/build/clang- linux-3.4/debug/threading-multi" -Wl,-R - Wl,"/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/timer/build/clang- linux-3.4/debug/threading-multi" -Wl,-rpath-link - Wl,"/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/atomic/build/clang- linux-3.4/debug/threading-multi" -Wl,-rpath-link - Wl,"/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/chrono/build/clang- linux-3.4/debug/threading-multi" -Wl,-rpath-link - Wl,"/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/system/build/clang- linux-3.4/debug/threading-multi" -Wl,-rpath-link - Wl,"/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/test/build/clang- linux-3.4/debug/threading-multi" -Wl,-rpath-link - Wl,"/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/thread/build/clang- linux-3.4/debug/threading-multi" -Wl,-rpath-link - Wl,"/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/timer/build/clang- linux-3.4/debug/threading-multi" -o "/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/atomic/test/atomicity.test/clang- linux-3.4/debug/threading-multi/atomicity" -Wl,--start-group "/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/atomic/test/atomicity.test/clang- linux-3.4/debug/threading-multi/atomicity.o" "/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/chrono/build/clang- linux-3.4/debug/threading-multi/libboost_chrono.so.1.58.0" "/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/thread/build/clang- linux-3.4/debug/threading-multi/libboost_thread.so.1.58.0" "/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/atomic/build/clang- linux-3.4/debug/threading-multi/libboost_atomic.so.1.58.0" "/home/tomkent/teeks99-03/j/results/boost/bin.v2/libs/system/build/clang- linux-3.4/debug/threading-multi/libboost_system.so.1.58.0" -Wl,-Bstatic - Wl,-Bdynamic -lrt -Wl,--end-group -g -pthread /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' clang: error: linker command failed with exit code 1 (use -v to see invocation) http://www.boost.org/development/tests/develop/developer/output/teeks99-03j-...

...

...
Were there other changes which removed main() definition from Boost.Test?

There were no changes in Boost.Test. All the changes that were done to upgrade to newer boost.timer were reverted.

Strange. Boost.Atomic tests also didn't change but were working before.

3527

Age (days ago)

3542

Last active (days ago)

List overview

Download

24 comments

8 participants

participants (8)

Adam Wulkiewicz
Andrey Semashev
Barend Gehrels
Beman Dawes
Gennadiy Rozental
Jürgen Hunold
Raffi Enficiaud
Vicente J. Botet Escriba