On Wed, Jun 8, 2016 at 8:13 AM, Peter Dimov 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

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(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::singletonboost::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::singletonboost::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::singletonboost::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::singletonboost::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::singletonboost::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.

...

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::singletonboost::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 Wed, Jun 8, 2016 at 8:10 PM, John Maddock 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::singletonboost::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 08 Jun 2016, at 18:24, Robert Ramey 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, std::allocator >::_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 10 Jun 2016, at 19:00, Robert Ramey 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