Re: [boost] [serialization] Linker errors in trunk
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? Regards Hartmut
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". Robert Ramey
Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
Robert Ramey wrote:
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):
[snip]
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.
Hmmm - let's think about this a little bit. We could change "exception_code" to something else. I don't
Hartmut Kaiser wrote: think it would break user code since user code might refer to the enum member names rather than the "exception_code".
Could you use BOOST_PREVENT_MACRO_SUBSTITUTION as is done for min/max? _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
AMDG Stewart, Robert wrote:
Robert Ramey wrote:
Hartmut Kaiser wrote:
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.
Could you use BOOST_PREVENT_MACRO_SUBSTITUTION as is done for min/max?
No. BOOST_PREVENT_MACRO_SUBSTITUTION only works for function like macros. In Christ, Steven Watanabe
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".
Any news? Regards Hartmut
I havn't ignored this. I've just been busy with other stuff. Is there a reason that an anomoly which doesn't affect the trunk testing is urgent? Robert Ramey Hartmut Kaiser wrote:
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".
Any news? Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I havn't ignored this. I've just been busy with other stuff.
No rush, just checking. Do you want me to create a ticket for this?
Is there a reason that an anomoly which doesn't affect the trunk testing is urgent?
Well, this might just be an indication that the testing on trunk isn't comprehensive, no? This problem potentially affects all Windows code linking against the dll version of the serialization libraries. So I think it's neither a local nor a insignificant anomaly. But to give you some consolation. It's not a problem for me as long as it doesn't show up in a release. I can always patch my trunk to make it working for me. Regards Hartmut
Robert Ramey
Hartmut Kaiser wrote:
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".
Any news? Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hartmut Kaiser wrote:
I havn't ignored this. I've just been busy with other stuff.
No rush, just checking. Do you want me to create a ticket for this?
That actually is the easiest way to make sure I don't forget.
https://svn.boost.org/trac/boost/ticket/3427 Regards Hartmut
participants (4)
-
Hartmut Kaiser -
Robert Ramey -
Steven Watanabe -
Stewart, Robert