MinGW: text_Xarchive_impl destructors marked dllimport

[Jim Bell <jim@…>]

The boost date_time regression test testgreg_serialize_dll won't compile, failing in archive's text_oarchive.hpp and text_iarchive.hpp:

In file included from ..\libs\date_time\test\gregorian\testgreg_serialize.cpp:8:
../boost/archive/text_oarchive.hpp:84: error: function
'boost::archive::text_oarchive_impl<Archive>::~text_oarchive_impl()' definition is marked dllimport

[...]

In file included from ..\libs\date_time\test\gregorian\testgreg_serialize.cpp:9:
../boost/archive/text_iarchive.hpp:91: error: function
'boost::archive::text_iarchive_impl<Archive>::~text_iarchive_impl()' definition is marked dllimport

[Jim Bell <jim@…>]

Symptom persists. See ​MinGW-32, ​MinGW-64, ​RW_Mingw45-0x.

[Jim Bell <jim@…>]

Defining BOOST_ARCHIVE_SOURCE in the compile corrects the symptom. Attached a patch to libs/date_time/test/Jamfile.v2

[Robert Ramey]

This cannot be the correct fix.

I did find the following in text_iarchive.hpp

    BOOST_ARCHIVE_DECL(BOOST_PP_EMPTY()) 
    ~text_iarchive_impl(){};

Which marks an inline function as imported. Of course this doesn't look correct and it seems that other compilers ignore it. I'll make this change and see if it fixes the problem.

Robert Ramey

[Jim Bell <jim@…>]

But doesn't BOOST_ARCHIVE_SOURCE signal that the archive is *NOT* in the DLL, which is the case for this test?

[Robert Ramey]

NO

BOOST_ARCHIVE_SOURCE signals that the modules should be compiled and exported. That is, BOOST_ARCHIVE_SOURCE should be used when the library is being built and ONLY then.

Any test which uses the the library should import the symbols from the library/dll. I believe that the source of this problem is that an inline function is being defined as imported. Since it's inline, it won't be found in the library. It seems that most compilers are ignoring the fact that it's marked imported and just use the inline definition. But this compiler is being a little more literal. Your fix would make it work - but at the expense of exported the newly defined inline function - an undesirable side effect. The real fix is in the library itself as I've noted above. I haven't had time to test it yet, but I'll be surprised if I'm wrong about this.

Robert Ramey

[Jim Bell <jim@…>]

The test compiles with BOOST_ALL_DYN_LINK, and with that defined, archives select only export or import (based on BOOST_ARCHIVE_SOURCE). Are you introducing a third way? A new BOOST_ARCHIVE_... flag? Won't that break existing code?

You say: Any test which uses the the library should import the symbols from the library/dll.

It does use the serialization DLL, but not the archive via DLL. In another situation, someone could put the archive in its own DLL, and would still use BOOST_ALL_DYN_LINK. The only flag distinguishing these two cases seems to be BOOST_ARCHIVE_SOURCE.

(Please forgive me for belaboring this.)

[Robert Ramey]

I don't understand the problem.

An inline function is marked import/export when it shouldn't be. One test one compiler fails because of this. Fixing the above mistake makes the test pass (I'm assuming) what's the problem.

if someone want's to make his own dll with the current source, that would be an entirely different issue - I haven't thought about any issues with this. In any case, that is outside the serialization library itself but rather an issue related to auto link which the serialization uses.

I probably won't be able to upload this for a week. Until that happens, I can't say much more about this.

Robert Ramey

[Jim Bell <jim@…>]

I think changing that function's import/export marking is going to break other things. I hope I'm wrong.