[serialization] mingw linker problems

Hi, We have an application comprised of many shared libraries. It is built on Windows using mingw (gcc 4.4) and on Mac OS X using gcc under the Qt 4.7.0 framework. The application has been based on boost 1_41. We are now attempting to port to boost 1_49. We use boost.serialization and other boost libraries as dlls. On Mac OS X the upgrade was mostly trouble free, but with mingw we have encountered problems with all of our libraries that use boost.serialization. Basically, the inclusion of boost.serialization code appears to alter the default symbol visibility of the dlls generated by mingw. 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. Please can anyone explain this? How does the use of boost.serialization change the global behaviour of mingw gcc in generating dll import libraries? TIA Ken Appleby

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

On 23/06/2012 01:23, Robert Ramey wrote:
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?
We don't currently use VS. I have a possible explanation and work-around now. We have been relying on the default behaviour of the gnu linker to export all symbols. boost.archive classes instantiated in our dll are probably specifying function attributes to implicitly export symbols. This appears to change the gnu linker behaviour. From "man ld": "--export-all-symbols If given, all global symbols in the objects used to build a DLL will be exported by the DLL. Note that this is the default if there otherwise wouldn't be any exported symbols. When symbols are explicitly exported via DEF files or implicitly exported via function attributes, the default is to not export anything else unless this option is given. " So using --export-all-symbols replaces the previous behaviour. Thanks for your swift response. Ken
participants (2)
-
Ken
-
Robert Ramey