Re: [boost] [serialization][trunk] mingw non-wide char regressions

From: John Maddock (john_at_[hidden])
Date: 2007-11-24 11:34:59

"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.