Hartmut Kaiser wrote:
Sorry, resending as it ended up on the wrong list...
-----------------------------
Since the latest changes in trunk I'm seeing linker errors while linking with the serialization library (VS2005 SP1, boost_serialization-vc80-mt-gd-1_40.lib):
runtime_support.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall boost::archive::archive_exception::archive_exception(enum boost::archive::archive_exception::_exception_code,char const *,char const *)"
(__imp_??0archive_exception@archive@boost@@QAE@W4_exception_code@012@PB
D1@Z)
(note the leading underscore in _exception_code)
Which is really strange as this symbol is the only missing one.
OTOH, the library exports the symbol:
boost::archive::archive_exception::archive_exception( enum boost::archive::archive_exception::exception_code, char const *,char const *);
(note the missing underscore in exception_code)
If I change the first parameter of the archive_exception constructor to be a 'int' everything builds fine.
Ok, I solved it. The MS header file excpt.h has a
#define exception_code _exception_code
which leads to problems if not consistently included. Doh! What a mess.
The bottom line is, that archive_exception.cpp needs to be compiled with exactly the same windows headers included (excpt.h gets included by windows.h) as any sources including archive_exception.hpp, which is generally not possible to ensure.
The only fail-proof way I could see is to always have
#if defined(BOOST_WINDOWS) #include <excpt.h> #endif
inside archive_exception.hpp, globally mapping exception_code to _exception_code. Patch attached. Ok to commit?
Hmmm - let's think about this a little bit. We could change "exception_code" to something else. I don't think it would break user code since user code might refer to the enum member names rather than the "exception_code".
Sure, should work as well. It's your decision... But please try to decide this as soon as possible, as currently it's just broken. Thanks! Regards Hartmut