[Serialization] linking problems leading to unregistered class exception
Hi, It seems I have linker-related problems leading to "unregistered class" exceptions being raised. Now, I know this sounds like a compilation chain-specific problem, but the thing is I get the exact same problem on Linux (Ubuntu 7.04, gcc4.1), Macosx 10.4 (gcc 4.0) and Windows (Microsoft Visual Studio 2005 Express). My initial problem was that I'm using Boost.Serialization on a rather big class hierarchy (around 200 classes), so instantiating all the serialization code in a single .cpp is not pratical (too much memory consumed by the compiler). So I split my BOOST_CLASS_EXPORT_GUID() declarations into several compilation units, and this worked fine. *Except* if I generate a static library, in which case I get unregistered class exceptions. If I take the same object files and link them into a dynamic library, or directly into my executable, then everything works as intended. So it looks like generating a static library (with gcc or msvc) leads to parts of the serialization code to disappear (a quick look at the file-size of the generated executables seems to confirm that). I attached the smallest test-case I could think of that reproduces this problem. The included Makefile will generate 3 executables: test_s11n, test_s11n_dyn, test_s11n_static. All of them build fine, but the last one fails at run-time. Anyone has some insight into this? Thanks, david.
David Raulo wrote:
My initial problem was that I'm using Boost.Serialization on a rather big class hierarchy (around 200 classes),
With a stack trace back i the debugger, you should be able to determine for which classes code is getting "dropped"
so instantiating all the serialization code in a single .cpp is not pratical (too much memory consumed by the compiler). So I split my BOOST_CLASS_EXPORT_GUID() declarations into several compilation units, and this worked fine. *Except* if I generate a static library, in which case I get unregistered class exceptions.
EXPORT assures that code for classes no otherwise referred to doesn't get "stripped". But if such code is added to a static library, I doubt it can be guarenteed that its added to the executable. I would guess you'll have to include a module in among your applications which explicitly refers to this code so it will be sucked into the executable. Robert Ramey
Hi,
Thanks for your response,
On Tue, 11 Sep 2007 07:53:09 -0700
"Robert Ramey"
With a stack trace back i the debugger, you should be able to determine for which classes code is getting "dropped"
EXPORT assures that code for classes no otherwise referred to doesn't get "stripped". But if such code is added to a static library, I doubt it can be guarenteed that its added to the executable. I would guess you'll have to include a module in among your applications which explicitly refers to this code so it will be sucked into the executable.
I am not sure I understand what you are suggesting. In the test-case I sent, all the serialization code related to the Derived class has been stripped from the third executable (the one generate with the static library). How should I modify this simple example to prevent that from happening? Explicitly call operator& on a Derived* object in main()? How would that generalize on my scenario of 200 serializable classes? David Raulo.
participants (2)
-
David Raulo -
Robert Ramey