Re: [boost] [serialization] Errors when testing withe mingw-64/gcc on Windows

Subject: Re: [boost] [serialization] Errors when testing withe mingw-64/gcc on Windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-08-03 14:58:43

On 7/18/2015 10:04 AM, Robert Ramey wrote:
> On 7/17/15 10:51 PM, Edward Diener wrote:
>> When running serialization tests with mingw-64/gcc on Windows I get
>> repeated errors of the form:
>>
>> ..\..\../boost/archive/detail/basic_oarchive.hpp:64:5: error: function
>> 'boost::archive::detail::helper_collection&
>> boost::archive::detail::basic_oarchive::get_helper_collection()'
>> definition is marked dllimport
>>       get_helper_collection(){
>>
>> Is this a known problem ?
>>
>> Testing with VC++ does not give any errors.
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>
> A couple of months ago I made efforts to limit symbol visibility on
> compilers other than Visual Studio.  This was to resolve complaints
> about the serialization library exporting many more symbols than
> necessary on these platforms.  This turned out to be quite a bit more
> intricate than I expected as there's some confusion between vs and other
> platforms on this point and they use different syntax.  I managed to get
> it all together - except for MinGW - which still has problems in this
> area.  I noticed it was failing the MinGW tests (when they were being
> run).  But I couldn't really fix it because I have neither Visual Studio
> nor MinGW.
>
> As I said, it turned out some what more complex than I expected due to
> one thing in particular.  The wide version of the DLL exports it's own
> symbols, but import symbols from the the base version of the DLL.  So
> one has to get it just right.  For a while I was experiencing the
> situation where fixing it for one version would create problems in the
> other.  I never could figure out which syntax MinGW uses.  If one has
> all three (or four) platforms gcc, mingw, clang, and Visual studion and
> some patience it's an easy fix - once you discover it.  But without this
> setup, it's sort of chasing one's tail.
>
> So if you want to do this, I would be grateful.  Not that if you get it
> wrong, it shows up in some tests but not in others.  So one has to be
> prepared to run the whole serialization test suite before declaring
> victory.

I don't know how "to run the whole serialization test suite" but here is 
what I have done:

1) I have created PR "Changes to fix serialization for gcc and clang on 
Windows #19". This fixes the building of the serialization library for 
mingw(-64)/gcc, both regular and wide character.

2) For clang I have been told that the system of exporting/importing 
individual member functions as opposed to entire class does not work, 
since clang will not export a class's RTTI unless the entire class is 
exported. So while the build of the regular serialization library 
succeeds it is probably not usable from other clang code. This can be 
seen in the fact that using your current system of exporting/importing 
individual member functions of a visible class I can not build the wide 
character serialization library using clang because it refuses to link 
with the dependent regular character serialization library. So unless 
you want to change the way that export/import works for clang on Windows 
clang on Windows will not work with serialization.

3) I have tested my changes with gcc and clang on Linux and with gcc, 
VC++, and clang on Windows. As explained above everything succeeds 
except clang on Windows, which also failed before my changes.

If you could look at this PR and try it with your "whole serialization 
test suite" it would be appreciated.

If you are willing to give the go ahead I can try changing clang on 
Windows so that the entire class is exported rather than individual 
member functions for that one-off case. It is pretty easy to test for 
clang on Windows using gcc at the preprocessor level. I do realize 
exporting the entire class in the one-off clang case changes your work 
in carefully honing visibility, for this single case, but I cannot 
change the way clang on Windows works. Changing for clang on Windows 
will not change any other compiler implementation but will make your 
code slightly messier.

PS. I also created PR "Delete recreated files. #18" which deletes some 
files from Git which were being regenerated by serialization tests each 
time.