[serialization][trunk] mingw non-wide char regressions
Hello, The trunk version of Boost.Serialization is having problems with all the DLL, non-wide char variants of MingW tests, see for instance http://tinyurl.com/2j7dq2 . Although it's not apparent from the regression tests output (the messages are totally misguiding), my local tests indicate that the problem is related to the inability of boost_serialization (no w) to build due to some mising std::codecvt<wchar_t, char, int> member functions. This is expected as MingW is long known to have defective wide char support. The reason why current tests are failing when they were passing in Boost 1.34.1 is the seemingly inadvertent move of codecvt_null from WSOURCES to SOURCES in boost/libs serialization/build/Jamfile.v2: Trunk: http://tinyurl.com/2wxjfy Boost 1.34.1: http://tinyurl.com/32bx8d codecvt_null.cpp deals exclusively with wchar_t functionality, so it need not be in boost_serialization, only in boost_wserialization. The attached patch corrects this. I've checked it locally in a MinGW installation and it makes (non-wide) serialization-dependent tests pass. OK to commit? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
"JOAQUIN LOPEZ MU?Z" wrote:
Hello,
The trunk version of Boost.Serialization is having problems with all the DLL, non-wide char variants of MingW tests, see for instance http://tinyurl.com/2j7dq2 . Although it's not apparent from the regression tests output (the messages are totally misguiding), my local tests indicate that the problem is related to the inability of boost_serialization (no w) to build due to some mising std::codecvt<wchar_t, char, int> member functions. This is expected as MingW is long known to have defective wide char support.
The reason why current tests are failing when they were passing in Boost 1.34.1 is the seemingly inadvertent move of codecvt_null from WSOURCES to SOURCES in boost/libs serialization/build/Jamfile.v2:
Trunk: http://tinyurl.com/2wxjfy Boost 1.34.1: http://tinyurl.com/32bx8d
codecvt_null.cpp deals exclusively with wchar_t functionality, so it need not be in boost_serialization, only in boost_wserialization. The attached patch corrects this. I've checked it locally in a MinGW installation and it makes (non-wide) serialization-dependent tests pass. OK to commit?
Please see http://lists.boost.org/Archives/boost/2007/11/130828.php and http://lists.boost.org/Archives/boost/2007/11/130831.php. My machine is tied up at present: can you double check that moving codecvt_null.cpp to boost_wserialization breaks dll building of Serialization with msvc? (I'm 99% sure it will do if the header is included by any of the sources). Then try Robert's suggestion of changing the export declaration to BOOST_WARCHIVE_DECL and see if it works as expected: you'll probably need to run the serialization regression tests with both msvc and mingw to be sure, which may take a while :-( HTH, John.
----- Mensaje original ----- De: John Maddock <john@johnmaddock.co.uk> Fecha: Sábado, Noviembre 24, 2007 2:41 pm Asunto: Re: [boost] [serialization][trunk] mingw non-wide char regressions Para: boost@lists.boost.org
"JOAQUIN LOPEZ MU?Z" wrote: [...]
codecvt_null.cpp deals exclusively with wchar_t functionality, so it need not be in boost_serialization, only in boost_wserialization. The attached patch corrects this. I've checked it locally in a MinGW installation and it makes (non-wide) serialization-dependent tests pass. OK to commit?
Please see http://lists.boost.org/Archives/boost/2007/11/130828.php and http://lists.boost.org/Archives/boost/2007/11/130831.php.
My machine is tied up at present: can you double check that moving codecvt_null.cpp to boost_wserialization breaks dll building of Serialization with msvc? (I'm 99% sure it will do if the header is included by any of the sources).
My results: 1. codecvt_null.cpp moved from SOURCES to WSOURCES. - MSVC++ 8.0: all tests pass - MinGW 3.4.5: narrow char tests pass (only tested a handful) 2. codecvt_null.cpp moved from SOURCES to WSOURCES, BOOST_ARCHIVE_DECL-->BOOST_WARCHIVE_DECL in codecvt_null.hpp, BOOST_ARCHIVE_SOURCE-->BOOST_WARCHIVE_SOURCE in codecvt_null.cpp (see attached diffs): - MSVC++ 8.0: all tests pass - MinGW 3.4.5: narrow char testspass (only tested a handful) Why do you assume moving codecvt_null.cpp from SOURCES to WSOURCES would break MSVC tests? If your concern is related to the possibility that codecvt_null<wchar_t> member functions aren't properly exported, take into account that exportability is not controled by the library the .cpp is bundled into, but only by the macros BOOST_[W]ARCHIVE_DECL and BOOST_[W]ARCHIVE_SOURCE: having the narrow version or the wide version of the macros in place make no difference, the end result is that the member functions are imported/exported as they should. Of course if we switch codecvt_null.cpp from SOURCES to WSOURCES having the wide macros rather than the narrow is the aesthetically consistent choice, but it makes no difference from a practical point of view, AFAICS. I don't have time now to additionally try Robert's suggestion of wrapping the wchar_t-related stuff in codecvt_null.hpp with a #ifndef BOOST_NO_STD_WSTREAMBUF guard, but I think it's probably equivalent to the patches I've just tried. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
"JOAQUIN LOPEZ MU?Z" wrote:
My machine is tied up at present: can you double check that moving codecvt_null.cpp to boost_wserialization breaks dll building of Serialization with msvc? (I'm 99% sure it will do if the header is included by any of the sources).
My results:
1. codecvt_null.cpp moved from SOURCES to WSOURCES. - MSVC++ 8.0: all tests pass - MinGW 3.4.5: narrow char tests pass (only tested a handful)
2. codecvt_null.cpp moved from SOURCES to WSOURCES, BOOST_ARCHIVE_DECL-->BOOST_WARCHIVE_DECL in codecvt_null.hpp, BOOST_ARCHIVE_SOURCE-->BOOST_WARCHIVE_SOURCE in codecvt_null.cpp (see attached diffs): - MSVC++ 8.0: all tests pass - MinGW 3.4.5: narrow char testspass (only tested a handful)
Why do you assume moving codecvt_null.cpp from SOURCES to WSOURCES would break MSVC tests? If your concern is related to the possibility that codecvt_null<wchar_t> member functions aren't properly exported, take into account that exportability is not controled by the library the .cpp is bundled into, but only by the macros BOOST_[W]ARCHIVE_DECL and BOOST_[W]ARCHIVE_SOURCE: having the narrow version or the wide version of the macros in place make no difference, the end result is that the member functions are imported/exported as they should. Of course if we switch codecvt_null.cpp from SOURCES to WSOURCES having the wide macros rather than the narrow is the aesthetically consistent choice, but it makes no difference from a practical point of view, AFAICS.
Hmm, as it stands: 1) When building the boost_serialization sources then the codecvt_null members are declared as exported, but aren't actually in the dll: in the past I've been hit by linker errors if you don't actually export everything you claim to, but strangely not in this case? 2) When building boost_wserialization sources other than codecvt_null.cpp then the codecvt_null are declared as imported, even though they are actually exported: that's normally a linker warning. I'm testing now with the macros changed to use the W variants... John.
John Maddock wrote:
I'm testing now with the macros changed to use the W variants...
OK, tested the patch below with msvc-8 and Mingw: there are no msvc-8 regressions and most of the Mingw tests now pass. Robert: does this look OK? John. Index: boost/archive/codecvt_null.hpp =================================================================== --- boost/archive/codecvt_null.hpp (revision 41302) +++ boost/archive/codecvt_null.hpp (working copy) @@ -59,7 +59,7 @@ template<> class codecvt_null<wchar_t> : public std::codecvt<wchar_t, char, std::mbstate_t
{ - virtual BOOST_ARCHIVE_DECL(std::codecvt_base::result) + virtual BOOST_WARCHIVE_DECL(std::codecvt_base::result) do_out( std::mbstate_t & state, const wchar_t * first1, @@ -69,7 +69,7 @@ char * last2, char * & next2 ) const; - virtual BOOST_ARCHIVE_DECL(std::codecvt_base::result) + virtual BOOST_WARCHIVE_DECL(std::codecvt_base::result) do_in( std::mbstate_t & state, const char * first1, Index: libs/serialization/build/Jamfile.v2 =================================================================== --- libs/serialization/build/Jamfile.v2 (revision 41302) +++ libs/serialization/build/Jamfile.v2 (working copy) @@ -44,7 +44,6 @@ basic_xml_archive binary_iarchive binary_oarchive - codecvt_null extended_type_info extended_type_info_no_rtti extended_type_info_typeid @@ -60,6 +59,7 @@ ; WSOURCES = + codecvt_null basic_text_wiprimitive basic_text_woprimitive binary_wiarchive @@ -86,4 +86,4 @@ <conditional>@include-spirit ; -boost-install boost_serialization boost_wserialization ; \ No newline at end of file +boost-install boost_serialization boost_wserialization ; Index: libs/serialization/src/codecvt_null.cpp =================================================================== --- libs/serialization/src/codecvt_null.cpp (revision 41302) +++ libs/serialization/src/codecvt_null.cpp (working copy) @@ -7,7 +7,7 @@ // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) -#define BOOST_ARCHIVE_SOURCE +#define BOOST_WARCHIVE_SOURCE #include <boost/archive/codecvt_null.hpp> // codecvt implementation for passing wchar_t objects to char output
----- Mensaje original ----- De: John Maddock <john@johnmaddock.co.uk> Fecha: Sábado, Noviembre 24, 2007 5:48 pm Asunto: Re: [boost] [serialization][trunk] mingw non-wide char regressions Para: boost@lists.boost.org
"JOAQUIN LOPEZ MU?Z" wrote:
Why do you assume moving codecvt_null.cpp from SOURCES to WSOURCES would break MSVC tests? If your concern is related to the possibility that codecvt_null<wchar_t> member functions aren't properly exported, take into account that exportability is not controled by the library the .cpp is bundled into, but only by the macros BOOST_[W]ARCHIVE_DECL and BOOST_[W]ARCHIVE_SOURCE: having the narrow version or the wide version of the macros in place make no difference, the end result is that the member functions are imported/exported as they should. Of course if we switch codecvt_null.cpp from SOURCES to WSOURCES having the wide macros rather than the narrow is the aesthetically consistent choice, but it makes no difference from a practical point of view, AFAICS.
Hmm, as it stands:
1) When building the boost_serialization sources then the codecvt_null members are declared as exported, but aren't actually in the dll: in the past I've been hit by linker errors if you don't actually export everything you claim to, but strangely not in this case?
No, I've just double checked it. To make surer I've conducted the following experiment: I created a toy DLL with the following source: #include <iostream> void __declspec(dllexport) f(); void __declspec(dllexport) g() { std::cout<<"hello"<<std::endl; } and a minimal program using it: void __declspec(dllimport) g(); int main() { g(); }; and everything works fine if I link the latter with the import lib of the former. If I change g() to f() in the program above there's an unresolved linking error for f(). Building the lib generates no error or warning, so my conclusion is that a __declspec(dllexport) *declaration* has no effect on the object code and hence generates no exported symbols. This is MSVC++ 8.0, maybe it was different with other compilers of the family.
2) When building boost_wserialization sources other than codecvt_null.cpp then the codecvt_null are declared as imported, even though they are actually exported: that's normally a linker warning.
Yep, what you say is very sensible, but the fact is that I observe no warnings whatsoever. Anyway, to be on the safe side is better to use the W macro variants for codecvt_null.{hpp|cpp} as I see you're proposing at another post of yours. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (2)
-
"JOAQUIN LOPEZ MU?Z" -
John Maddock