Jürgen Hunold wrote:
Hi Robert,
On Tuesday, 6. July 2010 00:07:48 you wrote:
Jürgen Hunold wrote:
BOOST_HAS_DECLSPEC is the interesting one. Please find a patch adding two more "#define BOOST_SERIALIZATION_SOURCE" to the sources. This fixed compilation for me when using gcc's symbol visibility and might help here as mingw uses symbol visibility "under the hood" for __declspec(dllimport/-export).
I'm aware of this "fix". I'm very reluctant to just do it because I don't understand why it works or should work.
It works because gcc and msvc have different symbol visibility rules. It seems to me that msvc works by "accident" or compiler "feature" right now. I've not taken the time to dig into the MS knowledge base to verify this, though.
So it's almost certain that if I just do this, It will come back to torture me some time just after the next version is released.
Well, I discovered this behaviour when trying to fix the now famous #2114
https://svn.boost.org/trac/boost/ticket/2114
As soons as symbol visibility support is added to the serialization library, gcc will fail on _all_ platforms without those extra "#defines"
That is, there won't be a problem with the serialization library until it changes to the new defines? That is as long as no one uses autolink for that library?
I'm quite short on time, but please find the whole patch adding symbols visibility support (and fixing #2114 for Boost.Serialization) attached. This already work for Boost.Test and Beman patched some more libs...
All this looks like a refinement of the auto-liink stuff which we've had for MSVC and Borland for years. So it's OK. I would like to see this stuff checked into the release branch before I make these changes in the serialization library. With the last change I made in the serialization library, the only missing symbols are void_upcast and void_downcast. the *.cpp files which defiine these functions to indeed define BOOST_SERIALIZATION_SOURCE so these symbols should be exported. I'm trying go figure out why this is not happening. Including define BOOST_SERIALIZATION_SOURCE in a different file can't be the solution - the fact that it seems to work can only be a hint as to what the problem is. Still thanks for the insight. Robert Ramey