Ken wrote:
Hi,
Basically, the inclusion of boost.serialization code appears to alter the default symbol visibility of the dlls generated by mingw.
Is this a mingw issue only or does it appear on regular VS C++ projects as well?
Each of our libraries consists of a declaration of a class, with public functions, and zero or more free functions. If the library implementation includes boost.archive or boost.serialization the public functions of the class, and any free functions declared, are missing from the import library, though visible in the dll.
Each of our libraries has a test executable, and with many it is a trivial task to comment out the use of boost.serialization in the library and test code. When we do that, there are no linker problems. As soon as we reintroduce functions that use boost.serialization into the library, the test function fails to find the public functions of the library class.
All functions or just the archive/serialization functions?
Please can anyone explain this? How does the use of boost.serialization change the global behaviour of mingw gcc in generating dll import libraries?
I can suggest you look at and build the serialization test suite under your mingw system. It includes several DLL projects which use boost serialization and regularly compile, link and run correctly with amost all platforms - including MingGw - see the dll lines on the test matrix.
TIA
Ken Appleby