[serialization] conflicting declaration (BOOST_CLASS_EXPORT)
Hi, I just had this similar error today, but it took me quite a few minutes to build a working "example". I'll start off with the error(s): L:\project\serializationtest\Mixed.hpp:27: error: conflicting declaration 'const boost::archive::detail::guid_initializer<Mixed>&<unnamed>::boost_serialization_guid_initializer_27' L:\project\serializationtest\Child.hpp:27: error: '<unnamed>::boost_serialization_guid_initializer_27' has a previous declaration as `const boost::archive::detail::guid_initializer<Child>&<unnamed>::boost_serialization_guid_initializer_27' L:\project\serializationtest\Mixed.hpp:27: error: type mismatch with previous external decl of `const boost::archive::detail::guid_initializer<Mixed>&<unnamed>::boost_serialization_guid_initializer_27' L:\project\serializationtest\Child.hpp:27: error: previous external decl of `const boost::archive::detail::guid_initializer<Child>&<unnamed>::boost_serialization_guid_initializer_27' L:\project\serializationtest\Mixed.hpp:27: error: declaration of `const boost::archive::detail::guid_initializer<Mixed>&<unnamed>::boost_serialization_guid_initializer_27' L:\project\serializationtest\Child.hpp:27: error: conflicts with previous declaration `const boost::archive::detail::guid_initializer<Child>&<unnamed>::boost_serialization_guid_initializer_27' :: === Build finished: 6 errors, 0 warnings === This is my class structure: Base Child : Base Mixed : Base or #include "Base.hpp" is actually enough. Easy, but maybe its already a hint to the problem. The "original" Class structure in my app is far more complex, so I just will refer to my little example, as I guess its the same source some how. I tend to believe that the problem resides somewhere in the Macro BOOST_CLASS_EXPORT, as the compiler points to this. I'm working on Windows XP, with MinGW and the latest (Monday) SVN Build of boost. (as serialization is in 1.36 partly broken afaik/imho). I'll attach my code. So, how to resolve this? regards Jens Weller
try the following re export: a) re-read the manual regarding boost class export b) Try using BOOST_CLASS_EXPORT only once. Robert Ramey jens weller wrote:
Hi,
I just had this similar error today, but it took me quite a few minutes to build a working "example".
I'll start off with the error(s): L:\project\serializationtest\Mixed.hpp:27: error: conflicting declaration 'const boost::archive::detail::guid_initializer<Mixed>&<unnamed>::boost_serialization_guid_initializer_27' L:\project\serializationtest\Child.hpp:27: error: '<unnamed>::boost_serialization_guid_initializer_27' has a previous declaration as `const boost::archive::detail::guid_initializer<Child>&<unnamed>::boost_serialization_guid_initializer_27' L:\project\serializationtest\Mixed.hpp:27: error: type mismatch with previous external decl of `const boost::archive::detail::guid_initializer<Mixed>&<unnamed>::boost_serialization_guid_initializer_27' L:\project\serializationtest\Child.hpp:27: error: previous external decl of `const boost::archive::detail::guid_initializer<Child>&<unnamed>::boost_serialization_guid_initializer_27' L:\project\serializationtest\Mixed.hpp:27: error: declaration of `const boost::archive::detail::guid_initializer<Mixed>&<unnamed>::boost_serialization_guid_initializer_27' L:\project\serializationtest\Child.hpp:27: error: conflicts with previous declaration `const boost::archive::detail::guid_initializer<Child>&<unnamed>::boost_serialization_guid_initializer_27'
=== Build finished: 6 errors, 0 warnings ===
This is my class structure:
Base Child : Base Mixed : Base or #include "Base.hpp" is actually enough.
Easy, but maybe its already a hint to the problem. The "original" Class structure in my app is far more complex, so I just will refer to my little example, as I guess its the same source some how. I tend to believe that the problem resides somewhere in the Macro BOOST_CLASS_EXPORT, as the compiler points to this. I'm working on Windows XP, with MinGW and the latest (Monday) SVN Build of boost. (as serialization is in 1.36 partly broken afaik/imho).
I'll attach my code.
So, how to resolve this?
regards
Jens Weller
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Robert Ramey wrote:
try the following re export:
a) re-read the manual regarding boost class export I did, any points you think about? b) Try using BOOST_CLASS_EXPORT only once.
So far I thought after each class I could just set a BOOST_CLASS_EXPORT($classname), as far as its derived from a serializable class. So, how to use it "only once"? Should I put those all in one file instead? ("exportmodel.hpp" f.e.) regards Jens Weller
jens weller wrote:
Robert Ramey wrote:
try the following re export:
a) re-read the manual regarding boost class export I did, any points you think about? b) Try using BOOST_CLASS_EXPORT only once.
So far I thought after each class I could just set a BOOST_CLASS_EXPORT($classname), as far as its derived from a serializable class. So, how to use it "only once"? Should I put those all in one file instead? ("exportmodel.hpp" f.e.)
Hi Jens, I think Robert means that BOOST_CLASS_EXPORT($classname) may only be expanded once in your program for a particular class name. And per the docs this expansion must occur within the context of all archive types that will be used to serialize the class. So rather than placing these macro calls in headers(which may be included in multiple translation units), place them in a cpp file that first includes the desired archive headers. Typically this would be in the class' implementation file. In the past I had placed them all in a single file, but quickly found the MSVC7.1 compiler limits, and had to break them up into export1.cpp, export2.cpp, ... Jeff Flinn
Jeff Flinn wrote:
jens weller wrote:
Robert Ramey wrote:
try the following re export:
a) re-read the manual regarding boost class export
I did, any points you think about?
b) Try using BOOST_CLASS_EXPORT only once.
So far I thought after each class I could just set a BOOST_CLASS_EXPORT($classname), as far as its derived from a serializable class. So, how to use it "only once"? Should I put those all in one file instead? ("exportmodel.hpp" f.e.)
Hi Jens,
I think Robert means that BOOST_CLASS_EXPORT($classname) may only be expanded once in your program for a particular class name. And per the docs this expansion must occur within the context of all archive types that will be used to serialize the class.
So rather than placing these macro calls in headers(which may be included in multiple translation units), place them in a cpp file that first includes the desired archive headers. Typically this would be in the class' implementation file. In the past I had placed them all in a single file, but quickly found the MSVC7.1 compiler limits, and had to break them up into export1.cpp, export2.cpp, ...
Thanks Jeff, putting it in the class.cpp is a solution. regards, Jens Weller
Jeff Flinn wrote:
jens weller wrote:
Robert Ramey wrote:
try the following re export:
a) re-read the manual regarding boost class export
I did, any points you think about?
b) Try using BOOST_CLASS_EXPORT only once.
So far I thought after each class I could just set a BOOST_CLASS_EXPORT($classname), as far as its derived from a serializable class. So, how to use it "only once"? Should I put those all in one file instead? ("exportmodel.hpp" f.e.)
Hi Jens,
I think Robert means that BOOST_CLASS_EXPORT($classname) may only be expanded once in your program for a particular class name. And per the docs this expansion must occur within the context of all archive types that will be used to serialize the class.
So rather than placing these macro calls in headers(which may be included in multiple translation units), place them in a cpp file that first includes the desired archive headers. Typically this would be in the class' implementation file. In the past I had placed them all in a single file, but quickly found the MSVC7.1 compiler limits, and had to break them up into export1.cpp, export2.cpp, ...
Jeff Flinn
Unfortunately it does not work for me. "Die Anweisung "0x00411b4c" verweist auf Speicher in "0x000000000". Der Vorgang "written" konnte nicht auf den Speicher durchgeführt werden." thats what I get as soon as I compile in Releasemode. Debug Version runs without errors, so I guess the code is ok. My Export.cpp: #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include "Include.hpp" #include "FileNode.hpp" #include "DirNode.hpp" #include "Observer.hpp" namespace codemodel { BOOST_CLASS_EXPORT( Include ) BOOST_CLASS_EXPORT( FileNode ) BOOST_CLASS_EXPORT( DirNode ) BOOST_CLASS_EXPORT( ParentNode ) //*/ } I'm using SVN Version of boost, about a week old. I currently have no short example, but will try to get one working. Anything wrong with this code? Any hints why it fails in Releasemode? regards, Jens Weller
jens weller wrote:
Jeff Flinn wrote:
jens weller wrote:
Robert Ramey wrote:
try the following re export:
a) re-read the manual regarding boost class export
I did, any points you think about?
b) Try using BOOST_CLASS_EXPORT only once.
So far I thought after each class I could just set a BOOST_CLASS_EXPORT($classname), as far as its derived from a serializable class. So, how to use it "only once"? Should I put those all in one file instead? ("exportmodel.hpp" f.e.)
Hi Jens,
I think Robert means that BOOST_CLASS_EXPORT($classname) may only be expanded once in your program for a particular class name. And per the docs this expansion must occur within the context of all archive types that will be used to serialize the class.
So rather than placing these macro calls in headers(which may be included in multiple translation units), place them in a cpp file that first includes the desired archive headers. Typically this would be in the class' implementation file. In the past I had placed them all in a single file, but quickly found the MSVC7.1 compiler limits, and had to break them up into export1.cpp, export2.cpp, ...
Jeff Flinn
Unfortunately it does not work for me.
"Die Anweisung "0x00411b4c" verweist auf Speicher in "0x000000000". Der Vorgang "written" konnte nicht auf den Speicher durchgeführt werden."
thats what I get as soon as I compile in Releasemode. Debug Version runs without errors, so I guess the code is ok.
My Export.cpp:
#include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include "Include.hpp" #include "FileNode.hpp" #include "DirNode.hpp" #include "Observer.hpp"
namespace codemodel { BOOST_CLASS_EXPORT( Include ) BOOST_CLASS_EXPORT( FileNode ) BOOST_CLASS_EXPORT( DirNode ) BOOST_CLASS_EXPORT( ParentNode ) //*/ }
I'm using SVN Version of boost, about a week old. I currently have no short example, but will try to get one working. Anything wrong with this code? Any hints why it fails in Releasemode?
Could be the code is being stripped from the release build? Sorry, meine deutsche rostig ist. :-) so I'm not positive of the compile/link error your getting. Jeff
Jeff Flinn wrote:
jens weller wrote:
Jeff Flinn wrote:
jens weller wrote:
Robert Ramey wrote:
try the following re export:
a) re-read the manual regarding boost class export
I did, any points you think about?
b) Try using BOOST_CLASS_EXPORT only once.
So far I thought after each class I could just set a BOOST_CLASS_EXPORT($classname), as far as its derived from a serializable class. So, how to use it "only once"? Should I put those all in one file instead? ("exportmodel.hpp" f.e.)
Hi Jens,
I think Robert means that BOOST_CLASS_EXPORT($classname) may only be expanded once in your program for a particular class name. And per the docs this expansion must occur within the context of all archive types that will be used to serialize the class.
So rather than placing these macro calls in headers(which may be included in multiple translation units), place them in a cpp file that first includes the desired archive headers. Typically this would be in the class' implementation file. In the past I had placed them all in a single file, but quickly found the MSVC7.1 compiler limits, and had to break them up into export1.cpp, export2.cpp, ...
Jeff Flinn
Unfortunately it does not work for me.
"Die Anweisung "0x00411b4c" verweist auf Speicher in "0x000000000". Der Vorgang "written" konnte nicht auf den Speicher durchgeführt werden."
thats what I get as soon as I compile in Releasemode. Debug Version runs without errors, so I guess the code is ok.
My Export.cpp:
#include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include "Include.hpp" #include "FileNode.hpp" #include "DirNode.hpp" #include "Observer.hpp"
namespace codemodel { BOOST_CLASS_EXPORT( Include ) BOOST_CLASS_EXPORT( FileNode ) BOOST_CLASS_EXPORT( DirNode ) BOOST_CLASS_EXPORT( ParentNode ) //*/ }
I'm using SVN Version of boost, about a week old. I currently have no short example, but will try to get one working. Anything wrong with this code? Any hints why it fails in Releasemode?
Could be the code is being stripped from the release build?
Sorry, meine deutsche rostig ist. :-) so I'm not positive of the compile/link error your getting.
Jeff
The program compiles. It crashes directly at start up. With write to 0x00000000, which I guess simply is an uninitialised pointer some where in the guts of BOOST_CLASS_EXPORT. As I said release -> crash, debug -> works fine. Also removing the BOOST_CLASS_EXPORT Macros removes the crash. So I doubt some how that this happens in my own code. Also placing the B_C_E macros in the main file, makes it(partly) work again, but thats no solution, and no explanation why it crashes if there somewhere else. Also in my main program, this does not work. I have a simple example, which I attach. I use MinGW under XP. regards, Jens Weller
I have a simple example, which I attach. I use MinGW under XP.
what compiler version. Do the serialization tests which use "EXPORT" also fail in your machine? Try building them this bjam. That is - try running the whole serialization test suite. If the all these serialization tests pass but your example fails, check to see that the compil/link switches are the same in both cases. Is there an environment similar to yours in the test matrix? All tests related to export passing except for one platform. Robert Ramey jens weller wrote:
Jeff Flinn wrote:
jens weller wrote:
Jeff Flinn wrote:
jens weller wrote:
Robert Ramey wrote:
try the following re export:
a) re-read the manual regarding boost class export
I did, any points you think about?
b) Try using BOOST_CLASS_EXPORT only once.
So far I thought after each class I could just set a BOOST_CLASS_EXPORT($classname), as far as its derived from a serializable class. So, how to use it "only once"? Should I put those all in one file instead? ("exportmodel.hpp" f.e.)
Hi Jens,
I think Robert means that BOOST_CLASS_EXPORT($classname) may only be expanded once in your program for a particular class name. And per the docs this expansion must occur within the context of all archive types that will be used to serialize the class.
So rather than placing these macro calls in headers(which may be included in multiple translation units), place them in a cpp file that first includes the desired archive headers. Typically this would be in the class' implementation file. In the past I had placed them all in a single file, but quickly found the MSVC7.1 compiler limits, and had to break them up into export1.cpp, export2.cpp, ...
Jeff Flinn
Unfortunately it does not work for me.
"Die Anweisung "0x00411b4c" verweist auf Speicher in "0x000000000". Der Vorgang "written" konnte nicht auf den Speicher durchgeführt werden."
thats what I get as soon as I compile in Releasemode. Debug Version runs without errors, so I guess the code is ok.
My Export.cpp:
#include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include "Include.hpp" #include "FileNode.hpp" #include "DirNode.hpp" #include "Observer.hpp"
namespace codemodel { BOOST_CLASS_EXPORT( Include ) BOOST_CLASS_EXPORT( FileNode ) BOOST_CLASS_EXPORT( DirNode ) BOOST_CLASS_EXPORT( ParentNode ) //*/ }
I'm using SVN Version of boost, about a week old. I currently have no short example, but will try to get one working. Anything wrong with this code? Any hints why it fails in Releasemode?
Could be the code is being stripped from the release build?
Sorry, meine deutsche rostig ist. :-) so I'm not positive of the compile/link error your getting.
Jeff
The program compiles. It crashes directly at start up. With write to 0x00000000, which I guess simply is an uninitialised pointer some where in the guts of BOOST_CLASS_EXPORT.
As I said release -> crash, debug -> works fine. Also removing the BOOST_CLASS_EXPORT Macros removes the crash. So I doubt some how that this happens in my own code.
Also placing the B_C_E macros in the main file, makes it(partly) work again, but thats no solution, and no explanation why it crashes if there somewhere else. Also in my main program, this does not work.
I have a simple example, which I attach. I use MinGW under XP.
regards,
Jens Weller
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
what compiler version. 3.4.2
Do the serialization tests which use "EXPORT" also fail in your machine? Try building them this bjam. That is - try running the whole serialization test suite.
How to start them with bjam? Also please note, that my exports are in a special file, as Jeff suggested.
If the all these serialization tests pass but your example fails, check to see that the compil/link switches are the same in both cases. I'll try as soon as I can.
Is there an environment similar to yours in the test matrix? All tests related to export passing except for one platform. Basicly I have 1. Baseclass, 2 derived, 1. exportfile.cpp, 1 main.cpp Dunno if you have such complex testcases.
regards, Jens Weller -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/616919...
The way I run the serialization tests is to run bjam as described in tools/regression/build/library_test.sh This creates a table similar to that shown at www.rrsd.com I should say however that for some time this only works with my microsoft compiler. You should be able to at least build all the demos. I'm not sure if any of them use the export functionality. Note that we've had lots of difficulties with export. This is due to the fact that it relies on indicating to the compiler that something shouldn't be stripped. The way of doing this is compiler dependent - see /boost/serialization/force_include. However, so far, we've been able to make this work on all compilers that boost uses. See the test matrix for the 1.36 release. I presume that these tests are run and built in release mode - but there isn't any way to actually know that. Robert Ramey Jens Weller wrote:
what compiler version. 3.4.2
Do the serialization tests which use "EXPORT" also fail in your machine? Try building them this bjam. That is - try running the whole serialization test suite.
How to start them with bjam? Also please note, that my exports are in a special file, as Jeff suggested.
If the all these serialization tests pass but your example fails, check to see that the compil/link switches are the same in both cases. I'll try as soon as I can.
Is there an environment similar to yours in the test matrix? All tests related to export passing except for one platform. Basicly I have 1. Baseclass, 2 derived, 1. exportfile.cpp, 1 main.cpp Dunno if you have such complex testcases.
regards,
Jens Weller
On Wed, Sep 24, 2008 at 9:43 PM, Robert Ramey <ramey@rrsd.com> wrote:
Note that we've had lots of difficulties with export. This is due to the fact that it relies on indicating to the compiler that something shouldn't be stripped. The way of doing this is compiler dependent - see
We've discussed this before -- not only it is compiler-dependent but a conforming compiler may not provide a way for this deadstripping to be disabled. Plus, isn't it somewhat disturbing that to use BOOST_CLASS_EXPORT we need to tell the compiler NOT to optimize aggressively? :) There is another problem as well: it is useful to be able to have a function which registers classes to be serialized, then serializes them, then frees all the memory taken by the registration (this is a separate issue, but being able to unregister also allows unloading of dynamic libraries.) So why not allocate the object that stores the registration state dynamically? For example, provide a factory function: shared_ptr<serialization_class_registry> create_serialization_class_registry(). Of course, the user is free to store the returned shared_ptr globally if that suits their taste. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
There is another problem as well: it is useful to be able to have a function which registers classes to be serialized, then serializes them, then frees all the memory taken by the registration (this is a separate issue, but being able to unregister also allows unloading of dynamic libraries.)
The current library provides a conforming method to "register" serialization types on an archive by archive basis. For their own reasons, many users have preferred the CLASS_EXPORT method with its attendant issues. Its really an issue with the way the user has chosen to use the library rather than the library itself.
So why not allocate the object that stores the registration state dynamically? For example, provide a factory function: shared_ptr<serialization_class_registry> create_serialization_class_registry(). Of course, the user is free to store the returned shared_ptr globally if that suits their taste.
As I understand this suggestion, I see no conflict with the current library if someone wants to do this. Robert Ramey
On Thu, Sep 25, 2008 at 9:59 AM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
There is another problem as well: it is useful to be able to have a function which registers classes to be serialized, then serializes them, then frees all the memory taken by the registration (this is a separate issue, but being able to unregister also allows unloading of dynamic libraries.)
The current library provides a conforming method to "register" serialization types on an archive by archive basis. For their own reasons, many users have preferred the CLASS_EXPORT method with its attendant issues. Its really an issue with the way the user has chosen to use the library rather than the library itself.
Could you point me to the documentation that describes the alternative to BOOST_CLASS_EXPORT mechanism to register base/derived types? I found the void_cast_register function but there should be more to it since the various templates for serializing user types need to be instantiated for the different archives, right? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Thu, Sep 25, 2008 at 9:59 AM, Robert Ramey <ramey@rrsd.com> wrote: Could you point me to the documentation that describes the alternative to BOOST_CLASS_EXPORT mechanism to register base/derived types? I found the void_cast_register function but there should be more to it since the various templates for serializing user types need to be instantiated for the different archives, right?
Look at the archive class. It contains a function call "register" which is used as ar.register(static_cast<myType *>(0)); This will "register" myType in archive instance ar. This is 100% failsafe and portable. Perhaps you might want to do something like template<class Archive> void register_all_my_types(Archive &ar){ ar.register(static_cast<myType *>(0)); ar.register(static_cast<myType2 *>(0)); ... } { text_oarchive oa(..); register_all_my_types(oa); ar << x; ar << y; ... }
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Robert Ramey wrote:
Emil Dotchevski wrote:
On Thu, Sep 25, 2008 at 9:59 AM, Robert Ramey <ramey@rrsd.com> wrote: Could you point me to the documentation that describes the alternative to BOOST_CLASS_EXPORT mechanism to register base/derived types? I found the void_cast_register function but there should be more to it since the various templates for serializing user types need to be instantiated for the different archives, right?
Look at the archive class. It contains a function call "register" which is used as ar.register(static_cast<myType *>(0)); This will "register" myType in archive instance ar. This is 100% failsafe and portable. Perhaps you might want to do something like
template<class Archive> void register_all_my_types(Archive &ar){ ar.register(static_cast<myType *>(0)); ar.register(static_cast<myType2 *>(0)); ... }
{ text_oarchive oa(..);
register_all_my_types(oa); ar << x; ar << y; ... }
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Thanks, this Idea works for me pretty good. And I prefer it instead of a static intialisation of my class types. regards, Jens Weller
AMDG Robert Ramey wrote:
Look at the archive class. It contains a function call "register" which is used as ar.register(static_cast<myType *>(0));
Isn't that register_type? register is a keyword. In Christ, Steven Watanabe
participants (7)
-
Emil Dotchevski -
Jeff Flinn -
jens weller -
Jens Weller
-
Jens Weller
-
Robert Ramey -
Steven Watanabe