About a month ago I got three new machines dedicated to testing boost online (thanks to Boost Community/Steering Committee/Conservancy!). These three machines are currently running tests along with a couple other machines that I have. Now that things are up and running, I'm looking for some community input as to how best utilize them. Here's the current setup: teeks99-01 - Ubuntu 14.04 + Docker - gcc-4.4 (master + develop) Docker precise + ubuntu-toolchain-r/test - gcc-4.5 (master + develop) Docker precise + ubuntu-toolchain-r/test - gcc-4.6 (master + develop) Docker precise + ubuntu-toolchain-r/test - gcc-4.7 (master + develop) Docker precise + ubuntu-toolchain-r/test - gcc-4.8 (master + develop) Docker trusty + ubuntu-toolchain-r/test - gcc-4.9 (master + develop) Docker trusty + ubuntu-toolchain-r/test - gcc-5 (master + develop) Docker trusty + ubuntu-toolchain-r/test - clang-3.0 (master + develop) Docker trusty + h-rayflood/llvm - clang-3.1 (master + develop) Docker trusty + h-rayflood/llvm - clang-3.2 (master + develop) Docker trusty + h-rayflood/llvm - clang-3.3 (master + develop) Docker trusty + ubuntu-toolchain-r/test - clang-3.4 (master + develop) Docker trusty + ubuntu-toolchain-r/test - clang-3.5 (master + develop) Docker trusty + ubuntu-toolchain-r/test - clang-3.6 (master + develop) Docker trusty - clang-3.7 (master + develop) Docker trusty + llvm.org/apt teeks99-02 - Ubuntu 16.04 + Docker - gcc-4.4 (master + develop) Docker precise + ubuntu-toolchain-r/test - gcc-4.5 (master + develop) Docker precise + ubuntu-toolchain-r/test - gcc-4.6 (master + develop) Docker precise + ubuntu-toolchain-r/test - gcc-4.7 (master + develop) Docker precise + ubuntu-toolchain-r/test - gcc-4.8 (master + develop) Docker trusty + ubuntu-toolchain-r/test - gcc-4.9 (master + develop) Docker trusty + ubuntu-toolchain-r/test - gcc-5 (master + develop) Docker trusty + ubuntu-toolchain-r/test - clang-3.0 (master + develop) Docker trusty + h-rayflood/llvm - clang-3.1 (master + develop) Docker trusty + h-rayflood/llvm - clang-3.2 (master + develop) Docker trusty + h-rayflood/llvm - clang-3.3 (master + develop) Docker trusty + ubuntu-toolchain-r/test - clang-3.4 (master + develop) Docker trusty + ubuntu-toolchain-r/test - clang-3.5 (master + develop) Docker trusty + ubuntu-toolchain-r/test - clang-3.6 (master + develop) Docker trusty - clang-3.7 (master + develop) Docker trusty + llvm.org/apt teeks99-03 - Ubuntu 16.04 + Docker - gcc-5 (develop) Docker trusty + ubuntu-toolchain-r/test - clang-3.7 (develop) Docker trusty + llvm.org/apt teeks99-05 - Ubuntu 14.04 (Azure VM) - gcc-4.8 (master) - clang-3.4 (master) teeks99-08 - Windows 2012 (KVM VM) - msvc-8.0 (master + develop) SP1 - msvc-9.0 (master + develop) SP1 - msvc-10.0 (master + develop) SP1 - msvc-11.0 (master + develop) Update 4 - msvc-12.0 (master + develop) Update 5 - msvc-14.0 (master + develop) Update 2 teeks99-09 - Windows 2012 (KVM VM) - msvc-8.0 (master + develop) SP1 - msvc-9.0 (master + develop) SP1 - msvc-10.0 (master + develop) SP1 - msvc-11.0 (master + develop) Update 4 - msvc-12.0 (master + develop) Update 5 - msvc-14.0 (master + develop) Update 2 I'm currently working on getting gcc-6 and clang 3.8, sorry they aren't in the list yet. I'm planning to retire the teeks99-01 shortly and converting the ancient teeks99-05 to something newer, still doing boost testing. All these configurations and the scripts that keep them cycling are on github at: https://github.com/teeks99/boost-build For each platform there are a couple configurations that I try to run frequently to give 'rapid' results as developers are committing code. The configurations for windows are set so that every few runs it will run the msvc-12.0 (develop) test, so that is never more than ~10hrs old. Similarly on linux, the gcc-5 and clang-3.7 (develp) tests get run every few hours. Just to give a feeling of the timing, Linux runs take .75-3 hrs and Windows runs take 1.5-4hrs, depending on compiler, os, hardware, etc. All these configurations have minimal compiler options set. MSVC + GCC builds have no options set, clang has `<cxxflags>-Wno-c99-extensions`.
From a lot of the discussing I've seen on the lists, it seems that there's a lot of work going into C++ 11/14/1z development. I was thinking it would be good to add some of those switches. Which ones? How many?
Baseline Standard -std=c++98 (I believe this is the default for all the g++/clang++ instances above) -std=c++11/0x -std=c++14/1y -std=c++1z GNU Standard -std=gnu++98 -std=gnu++11/0x -std=gnu++14/1y -std=gnu++1z Clang Library -stdlib=libc++ -stdlib=libstdc++ Optimization -O2? Warnings -Wall -Wextra Others? I'm guessing that most of these will be of interest to at least a small subset of developers. There probably isn't a need to apply all possible combinations to all possible compilers however. (Not to mention that it would make the results matrix even more overwhelming.) Which combinations are important for you to see in the matrix? What do you think should be the 'rapid' configurations? I'm also thinking about additional compilers (in addition to gcc-6/clang-3.9 mentioned above), though these will take a bit of work on my part, so will only get implemented as I have time available. - gcc HEAD from GIT - clang HEAD from GIT - cygwin/gcc - mingw - clang on windows - Other? Thanks in advance for your input! Tom
Tom Kent wrote:
From a lot of the discussing I've seen on the lists, it seems that there's a lot of work going into C++ 11/14/1z development. I was thinking it would be good to add some of those switches. Which ones? How many?
Baseline Standard -std=c++98 (I believe this is the default for all the g++/clang++ instances above) -std=c++11/0x -std=c++14/1y -std=c++1z
We definitely need those. Testing a recent version of g++ (or any version of clang) in its default 98 mode isn't very useful. We need c++11 at the very minimum because without it half of the code isn't tested. On the other hand, testing all compilers in all modes would be impractical. Some sort of a compromise needs to be struck, but I'm not sure how. The rapid configuration should probably be the latest -std supported by a particular version.
- cygwin/gcc
This is an undertested configuration so it would probably be nice if it's added, even though it's not important in practice.
On Wed, Jun 8, 2016 at 8:13 AM, Peter Dimov <lists@pdimov.com> wrote:
Tom Kent wrote:
From a lot of the discussing I've seen on the lists, it seems that there's a lot of work going into C++ 11/14/1z development. I was thinking it would be good to add some of those switches. Which ones? How many?
Baseline Standard -std=c++98 (I believe this is the default for all the g++/clang++ instances above) -std=c++11/0x -std=c++14/1y -std=c++1z
And now MSVC is also adding similar but different /std options.
We definitely need those. Testing a recent version of g++ (or any version of clang) in its default 98 mode isn't very useful. We need c++11 at the very minimum because without it half of the code isn't tested.
+1 ISTM we are at the point where c++11 should be the default for gcc & clang, and we spend ever less testing and development resources on c++98 for those compilers. Likewise with MSVC we concentrate resources on more recent release.
On the other hand, testing all compilers in all modes would be impractical. Some sort of a compromise needs to be struck, but I'm not sure how.
Maybe divide the world into rapid, default, and legacy. Currently, rapid == latest, default == c++11, and legacy == c++98 and older compilers. Rapid runs as often as possible, default runs daily, legacy into three groups cycling every third day. Or something similar. Incidentally, I see rapid as only a stopgap until we have a real continuous integration mechanism in place --Beman
On 6/7/16 4:54 AM, Tom Kent wrote:
About a month ago I got three new machines dedicated to testing boost online (thanks to Boost Community/Steering Committee/Conservancy!). These three machines are currently running tests along with a couple other machines that I have. Now that things are up and running, I'm looking for some community input as to how best utilize them.
Here's the current setup:
teeks99-01 - Ubuntu 14.04 + Docker - gcc-4.4 (master + develop) Docker precise + ubuntu-toolchain-r/test - gcc-4.5 (master + develop) Docker precise + ubuntu-toolchain-r/test - gcc-4.6 (master + develop) Docker precise + ubuntu-toolchain-r/test - gcc-4.7 (master + develop) Docker precise + ubuntu-toolchain-r/test - gcc-4.8 (master + develop) Docker trusty + ubuntu-toolchain-r/test - gcc-4.9 (master + develop) Docker trusty + ubuntu-toolchain-r/test
I have problems with the current test system. I don't know if this is the place to describe them, but I posted on the test list and haven't gotten any response. Basically I have a test failures on all gcc compilers on the develop branch of the test matrix. But I test one gcc compilers (gcc-5.1) on my local evironment (MacOS) in all combinations release/debug, shared/static, std=C++11/C++03 and everything passes (except of a bugs in the gcc library). So I'm at a loss to determine the cause of the issue and the test system is standing in my way. http://www.boost.org/development/tests/develop/teeks99-02gm-Ubuntu16-04-64on... show some information about the test environment - but I can't figure out what configuration debug/release ... it's using to run the tests. http://www.boost.org/development/tests/develop/developer/output/teeks99-02gm... shows some more information. One thing that jumps out is that there is no -DBOOST_SERIALIZATION_DYN_LINK=1 on the command line which seems to suggest that the serialization library is being linked statically while other libraries are being linked dynamically. This is usually a non-starter at least with msvc/windows. On the other hand, the tests on the master seem to have no problem with this. The whole thing is a mystery to me. Another thing - all the tests on Mingw fail due to a complaint about the visibility attribute set to import from the serialization DLL. Of course that is exactly what we want to do! I also tried cygwin on my local machine but due to issues I could never straighten out, I couldn't get it to work. I used to do this all the time but now I don't. Finally, although I don't have this problem now, compilation errors get truncated too short. If one has a long list of warnings - which I get with spirit - any real errors are lost - this makes it very, very, very hard to find a mistake. At the very least we should have some way to see all the configuration which is being tested. Longer run, I'd prefer to see a whole different approach to testing. Robert Ramey
I have problems with the current test system. I don't know if this is the place to describe them, but I posted on the test list and haven't gotten any response.
Basically I have a test failures on all gcc compilers on the develop branch of the test matrix. But I test one gcc compilers (gcc-5.1) on my local evironment (MacOS) in all combinations release/debug, shared/static, std=C++11/C++03 and everything passes (except of a bugs in the gcc library). So I'm at a loss to determine the cause of the issue and the test system is standing in my way.
My guess is there's an integration issue, are you testing against "everything else develop"?
Another thing - all the tests on Mingw fail due to a complaint about the visibility attribute set to import from the serialization DLL. Of course that is exactly what we want to do! I also tried cygwin on my local machine but due to issues I could never straighten out, I couldn't get it to work. I used to do this all the time but now I don't.
That's an error in the header - the constructor is declared imported but has an inline function body: BOOST_UTF8_DECL explicit utf8_codecvt_facet(std::size_t no_locale_manage=0) : std::codecvt<wchar_t, char, std::mbstate_t>(no_locale_manage) {} // <---- error here, can't import a definition! I also see a whole load of linker errors which I don't understand at present: gcc.link.dll ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\libboost_serialization-mgw53-d-1_62.dll.a ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\binary_iarchive.o: In function `boost::serialization::singleton<boost::archive::detail::extra_detail::map<boost::archive::binary_iarchive>
::get_mutable_instance()': M:\data\boost\boost\libs\serialization\build/../../../boost/serialization/singleton.hpp:131: undefined reference to `__imp__ZN5boost13serialization16singleton_module9is_lockedEv' ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\binary_oarchive.o: In function `boost::serialization::singleton<boost::archive::detail::extra_detail::map<boost::archive::binary_oarchive> ::get_mutable_instance()': M:\data\boost\boost\libs\serialization\build/../../../boost/serialization/singleton.hpp:131: undefined reference to `__imp__ZN5boost13serialization16singleton_module9is_lockedEv' ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\polymorphic_iarchive.o: In function `boost::serialization::singleton<boost::archive::detail::extra_detail::map<boost::archive::polymorphic_iarchive> ::get_mutable_instance()': ':M:\data\boost\boost\libs\serialization\build/../../../boost/serialization/singleton.hpp:131: undefined reference to `__imp__ZN5boost13serialization16singleton_module9is_lockedEv' ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\polymorphic_oarchive.o: In function `boost::serialization::singleton<boost::archive::detail::extra_detail::map<boost::archive::polymorphic_oarchive> ::get_mutable_instance()': M:\data\boost\boost\libs\serialization\build/../../../boost/serialization/singleton.hpp:131: undefined reference to `__imp__ZN5boost13serialization16singleton_module9is_lockedEv' ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\text_iarchive.o: In function `boost::serialization::singleton<boost::archive::detail::extra_detail::map<boost::archive::text_iarchive> ::get_mutable_instance()': M:\data\boost\boost\libs\serialization\build/../../../boost/serialization/singleton.hpp:131: undefined reference to `__imp__ZN5boost13serialization16singleton_module9is_lockedEv' ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\text_oarchive.o:M:\data\boost\boost\libs\serialization\build/../../../boost/serialization/singleton.hpp:131: more undefined references to `__imp__ZN5boost13serialization16singleton_module9is_lockedEv' follow
HTH, John.
On 6/8/16 11:10 AM, John Maddock wrote:
I have problems with the current test system. I don't know if this is the place to describe them, but I posted on the test list and haven't gotten any response.
Basically I have a test failures on all gcc compilers on the develop branch of the test matrix. But I test one gcc compilers (gcc-5.1) on my local evironment (MacOS) in all combinations release/debug, shared/static, std=C++11/C++03 and everything passes (except of a bugs in the gcc library). So I'm at a loss to determine the cause of the issue and the test system is standing in my way.
My guess is there's an integration issue, are you testing against "everything else develop"?
No - I'm testing with "everything else master" Why would this be relevant?
Another thing - all the tests on Mingw fail due to a complaint about the visibility attribute set to import from the serialization DLL. Of course that is exactly what we want to do! I also tried cygwin on my local machine but due to issues I could never straighten out, I couldn't get it to work. I used to do this all the time but now I don't.
That's an error in the header - the constructor is declared imported but has an inline function body:
BOOST_UTF8_DECL explicit utf8_codecvt_facet(std::size_t no_locale_manage=0) : std::codecvt<wchar_t, char, std::mbstate_t>(no_locale_manage) {} // <---- error here, can't import a definition!
I've checked in a correction for this but the relevant test hasn't cycled yet.
I also see a whole load of linker errors which I don't understand at present:
gcc.link.dll ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\libboost_serialization-mgw53-d-1_62.dll.a
..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\binary_iarchive.o: In function `boost::serialization::singleton<boost::archive::detail::extra_detail::map<boost::archive::binary_iarchive>
::get_mutable_instance()': M:\data\boost\boost\libs\serialization\build/../../../boost/serialization/singleton.hpp:131: undefined reference to `__imp__ZN5boost13serialization16singleton_module9is_lockedEv' ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\binary_oarchive.o:
<snip> I'm not seeing this in any other platforms.
HTH, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I also see a whole load of linker errors which I don't understand at present:
gcc.link.dll ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\libboost_serialization-mgw53-d-1_62.dll.a
..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\binary_iarchive.o:
In function `boost::serialization::singleton<boost::archive::detail::extra_detail::map<boost::archive::binary_iarchive>
::get_mutable_instance()': M:\data\boost\boost\libs\serialization\build/../../../boost/serialization/singleton.hpp:131:
undefined reference to `__imp__ZN5boost13serialization16singleton_module9is_lockedEv' ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\binary_oarchive.o:
<snip> I'm not seeing this in any other platforms.
and I'm not seeing this on the test matrix even for mingw. Another thing that intrigues me is the command line "g++-4.4" -ftemplate-depth-128 -Wno-c99-extensions -O0 -fno-inline -Wall -g -fPIC -m64 -Wno-unused-variable -Wno-long-long -ftemplate-depth-255 -DBOOST_ALL_NO_LIB=1 -DBOOST_ARCHIVE_TEST=binary_archive.hpp -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LIB_DIAGNOSTIC=1 -DBOOST_SYSTEM_DYN_LINK=1 -D_GLIBCXX_DEBUG -D_STLP_DEBUG -I".." -c -o "/var/boost/run/results/boost/bin.v2/libs/serialization/test/test_binary_binary_archive.test/gcc-4.4/dbg/test_binary.o" "../libs/serialization/test/test_binary.cpp" I expect to see that -DBOOST_SERIALIZATION_DYN_LINK=1 and -DBOOST_WSERIALIZATION_DYN_LINK=1 as well. It looks like the serialization libraries are being linked statically while the other libraries used in the test are being linked through DLLS. My recollection is that this will link to both the static and shared C++ runtime libraries which is known to cause serious problems. What am I missing here? Also it's true that on my own system, I run develop branch for the libraries I'm testing against the master branch of all other libraries. This is different from the test matrix system which runs all packages from the develop or all packages from the master branch. The fact that gcc passes on my system and fails on the test matrix might suggest that a bug or breaking change has been checked into the develop branch which is not being caught by some test. I don't know. I'm tempted to merge the serialization develop into the master just to see what happens - but I'm reluctant to go down that past. My confidence in the test system has atrophied. Robert Ramey
HTH, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 14 Jun 2016, at 18:23, Robert Ramey <ramey@rrsd.com> wrote:
The fact that gcc passes on my system and fails on the test matrix might suggest that a bug or breaking change has been checked into the develop branch which is not being caught by some test.
Are you actually using mingw or just gcc on a different platform? I’m not sure they can be treated automatically the same after you leave the compilation stage since mingw has to deal with the intricacies of Windows. For your actual problem: the __imp__ prefix means that the linker expects the function to live in a DLL but it’s actually in the lib itself (without the __imp__, using objdump). Might be a problem with BOOST_DLLEXPORT or some build settings. Thomas
On Wed, Jun 8, 2016 at 8:10 PM, John Maddock <jz.maddock@googlemail.com> wrote:
I also see a whole load of linker errors which I don't understand at present:
gcc.link.dll ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\libboost_serialization-mgw53-d-1_62.dll.a ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\binary_iarchive.o: In function `boost::serialization::singleton<boost::archive::detail::extra_detail::map<boost::archive::binary_iarchive>
::get_mutable_instance()': M:\data\boost\boost\libs\serialization\build/../../../boost/serialization/singleton.hpp:131: undefined reference to `__imp__ZN5boost13serialization16singleton_module9is_lockedEv'
The problem is that "BOOST_SERIALIZATION_DECL" expands to "__attribute__((__dllimport__))" in "singleton.hpp" when it is included from files that don't define "BOOST_SERIALIZATION_SOURCE" e.g. "binary_iarchive.cpp". Thomas
On 6/22/16 3:31 AM, Thomas Trummer wrote:
On Wed, Jun 8, 2016 at 8:10 PM, John Maddock <jz.maddock@googlemail.com> wrote:
I also see a whole load of linker errors which I don't understand at present:
gcc.link.dll ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\libboost_serialization-mgw53-d-1_62.dll.a ..\..\..\bin.v2\libs\serialization\build\gcc-mingw-5.3.0s14\debug\binary_iarchive.o: In function `boost::serialization::singleton<boost::archive::detail::extra_detail::map<boost::archive::binary_iarchive>
::get_mutable_instance()': M:\data\boost\boost\libs\serialization\build/../../../boost/serialization/singleton.hpp:131: undefined reference to `__imp__ZN5boost13serialization16singleton_module9is_lockedEv'
The problem is that "BOOST_SERIALIZATION_DECL" expands to "__attribute__((__dllimport__))" in "singleton.hpp" when it is included from files that don't define "BOOST_SERIALIZATION_SOURCE" e.g. "binary_iarchive.cpp".
interesting observation. I'll look into this.
Thomas
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 08 Jun 2016, at 18:24, Robert Ramey <ramey@rrsd.com> wrote:
I also tried cygwin on my local machine but due to issues I could never straighten out, I couldn't get it to work. I used to do this all the time but now I don't.
I run the test-runner for cygwin on develop. All the tests seem to fail with a core dump in libstdc++ in [std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_mutate(unsigned long, unsigned long, unsigned long)] (to a point where a backtrace fails). Is this the same issue you’ve mentioned? If not I can try to investigate further… Thomas
On 6/8/16 12:40 PM, Thomas Trummer wrote:
On 08 Jun 2016, at 18:24, Robert Ramey <ramey@rrsd.com> wrote:
I also tried cygwin on my local machine but due to issues I could never straighten out, I couldn't get it to work. I used to do this all the time but now I don't.
I run the test-runner for cygwin on develop. All the tests seem to fail with a core dump in libstdc++ in
[std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_mutate(unsigned long, unsigned long, unsigned long)]
(to a point where a backtrace fails). Is this the same issue you’ve mentioned?
could be. But it doesn't tell me what to fix If not I can try to investigate further…
Thomas
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 10 Jun 2016, at 19:00, Robert Ramey <ramey@rrsd.com> wrote:
could be. But it doesn't tell me what to fix
So the problem seems to be this line: https://github.com/boostorg/serialization/blob/develop/test/test_tools.hpp#L... I’m not sure yet if this is problem in Boost.Filesystem or cygwin… Independent of the problem there is 'temp_directory_path()’ in Boost.Filesystem which may help to get rid of some code in that place. Thomas
participants (6)
-
Beman Dawes -
John Maddock -
Peter Dimov -
Robert Ramey -
Thomas Trummer -
Tom Kent