Serialization triggers .lib and .exp file generation in VS2005
Hi, I tried to use boost serializing for a std::set. The serializing itself works fine, however, after implementing the serialization the compiler started to generate a .exp and a .lib file, even though the application is no DLL. Since the application is large and generating those files takes some time I tracked down the reason, and was surprised to realize that it was the serialization that triggered it. More precisely, the .lib and .exp will be generated if (and only if) I include the 4 lines of code calling the serialization. Any ideas? Boost version is 1.35, Visual Studio 2005 english SP1 on WinXP. Here is the sample (the part that loads the data, the writing part is symmetric): -------------------------- std::istringstream iss(serialized_string); #ifdef SERIALIZE boost::archive::text_iarchive ia(iss); ia >> *myclass; #endif -------------------------- where myclass is a shared pointer to a class that looks basically like this: ----------------------- class foo { std::set<SomeClass> _members; std::string _name; template<class Archive> void serialize(Archive& ar, const unsigned int version) { ar & _name; ar & _members; } } --------------------------- with a custom serialization routine for SomeClass. Any help is appreciated. If there is a mailing list better suited for this discussion then please point me there, I'm new here :-) Regards, Thomas
This is a side effect of the steps taken inhibit the compiler from eliminationg code not explicitly referred to. (aka code stripping). Just ignore the *.exp and *.lib files. I 'm surprised that they take a lot of time to generate but I don't know how to avoid it and have the serialization library still work as advertised. Robert Ramey Thomas Voigt wrote:
Hi,
I tried to use boost serializing for a std::set. The serializing itself works fine, however, after implementing the serialization the compiler started to generate a .exp and a .lib file, even though the application is no DLL.
Since the application is large and generating those files takes some time I tracked down the reason, and was surprised to realize that it was the serialization that triggered it. More precisely, the .lib and .exp will be generated if (and only if) I include the 4 lines of code calling the serialization.
Any ideas? Boost version is 1.35, Visual Studio 2005 english SP1 on WinXP. Here is the sample (the part that loads the data, the writing part is symmetric):
-------------------------- std::istringstream iss(serialized_string); #ifdef SERIALIZE boost::archive::text_iarchive ia(iss); ia >> *myclass; #endif --------------------------
where myclass is a shared pointer to a class that looks basically like this: ----------------------- class foo { std::set<SomeClass> _members; std::string _name;
template<class Archive> void serialize(Archive& ar, const unsigned int version) { ar & _name; ar & _members; } } ---------------------------
with a custom serialization routine for SomeClass.
Any help is appreciated. If there is a mailing list better suited for this discussion then please point me there, I'm new here :-)
Regards, Thomas
Robert Ramey schrieb:
This is a side effect of the steps taken inhibit the compiler from eliminationg code not explicitly referred to. (aka code stripping).
So is there a way around it? Since we use boost in a rather controlled environment (only VS2005) we could patch it locally.
Just ignore the *.exp and *.lib files. I 'm surprised that they take a lot of time to generate but I don't know how to avoid it and have the serialization library still work as advertised.
I would estimate that the generation takes 20-30 seconds. This may not seem long, but it adds up over the course of a day. Regards, Thomas
well, we wouldn't put it in there if there was an easy way around it. You could comment out all the _export keywords in the code. But its doubtful that serialization of pointers could be made to work. good luck with that. Robert Ramey Thomas Voigt wrote:
Robert Ramey schrieb:
This is a side effect of the steps taken inhibit the compiler from eliminationg code not explicitly referred to. (aka code stripping).
So is there a way around it? Since we use boost in a rather controlled environment (only VS2005) we could patch it locally.
Just ignore the *.exp and *.lib files. I 'm surprised that they take a lot of time to generate but I don't know how to avoid it and have the serialization library still work as advertised.
I would estimate that the generation takes 20-30 seconds. This may not seem long, but it adds up over the course of a day.
Regards, Thomas
Robert Ramey schrieb:
well, we wouldn't put it in there if there was an easy way around it.
You could comment out all the _export keywords in the code. But its doubtful that serialization of pointers could be made to work.
Well, since nobody can help we'll have to figure it out for ourselves. For starters we disabled the #if defined(BOOST_HAS_DECLSPEC) && !defined(__COMO__) # if defined(__BORLANDC__) # define BOOST_DLLEXPORT __export # else # define BOOST_DLLEXPORT __declspec(dllexport) # endif #elif ! defined(_WIN32) && ! defined(_WIN64) # if defined(__MWERKS__) # define BOOST_DLLEXPORT __declspec(dllexport) # elif defined(__GNUC__) && (__GNUC__ >= 3) # define BOOST_USED __attribute__ ((used)) # elif defined(__INTEL_COMPILER) && (BOOST_INTEL_CXX_VERSION >= 800) # define BOOST_USED __attribute__ ((used)) # endif #endif block in serialization/force_include.hpp, which fixes our problem. The first few lines seem to be wrong, a __declspec(dllexport) should never be visible unless a DLL is generated. Regards, tv
Thomas Voigt wrote:
Robert Ramey schrieb:
well, we wouldn't put it in there if there was an easy way around it.
You could comment out all the _export keywords in the code. But its doubtful that serialization of pointers could be made to work.
Well, since nobody can help we'll have to figure it out for ourselves.
Way to go !!!
For starters we disabled the
#if defined(BOOST_HAS_DECLSPEC) && !defined(__COMO__) # if defined(__BORLANDC__) # define BOOST_DLLEXPORT __export # else # define BOOST_DLLEXPORT __declspec(dllexport) # endif #elif ! defined(_WIN32) && ! defined(_WIN64) # if defined(__MWERKS__) # define BOOST_DLLEXPORT __declspec(dllexport) # elif defined(__GNUC__) && (__GNUC__ >= 3) # define BOOST_USED __attribute__ ((used)) # elif defined(__INTEL_COMPILER) && (BOOST_INTEL_CXX_VERSION >= 800) # define BOOST_USED __attribute__ ((used)) # endif #endif
block in serialization/force_include.hpp, which fixes our problem. The first few lines seem to be wrong, a __declspec(dllexport) should never be visible unless a DLL is generated.
Which it when this is included in the library build. Robert Ramey
Regards, tv
participants (2)
-
Robert Ramey -
Thomas Voigt