Re: [Boost-bugs] [Boost C++ Libraries] #5341: Patch to improve shared library behavior with serialization

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #5341: Patch to improve shared library behavior with serialization
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-04-23 01:51:50

#5341: Patch to improve shared library behavior with serialization
----------------------------------------------+-----------------------------
  Reporter:  Aaron Barany <akb825@…>          |       Owner:  ramey                              
      Type:  Patches                          |      Status:  closed                             
 Milestone:  To Be Determined                 |   Component:  serialization                      
   Version:  Boost 1.46.0                     |    Severity:  Problem                            
Resolution:  wontfix                          |    Keywords:  serialization shared_libraries dlls
----------------------------------------------+-----------------------------

Comment (by Aaron Barany <akb825@…>):

 The problem with the current method is all instantiations of
 archive_serializer_map are always set to export for the boost
 serialization DLL, and set to import for all other libraries, which causes
 issues due to the fact that it’s templated. This makes it impossible to
 create your own archive outside of the boost serialization DLL. I will lay
 out every step of why this is the case.

 I will first start with how template instantiation works. When you
 instantiate a templated class, it is as if you are creating a completely
 new, unrelated type. For example, let’s say you have a template class Foo.
 If you have a template instantiation for type A and type B, you have
 Foo<A> and Foo<B>. As far as the compiler is concerned, you might as well
 have separately created two unrelated classes, Foo_A and Foo_B.
 Additionally, these separate templated types are created in whatever
 library they are instantiated in. For example, let’s say you declare your
 templated Foo type in Library1, and instantiate Foo<A> in Library2 and
 Foo<B> in Library3. This is equivalent to creating nothing in Library1,
 creating a class Foo_A in Library2, and a completely unrelated class Foo_B
 in Library3.

 Now I will cover how DLL symbol importing and exporting work in the
 Microsoft compiler. When compiling a library, you must declare all symbols
 you want to expose to external libraries to export. When compiling code
 that utilizes that library, all declarations of those symbols must be
 declared to import. Exported symbols must have an implementation, while
 imported symbols may not have an implementation. Choosing whether to
 export or import a symbol is typically done with a macro, which resolves
 to export when compiling the library, and import when compiling other
 libraries and executables that utilize that library.

 Now in this case we must combine both templated classes and DLL importing
 and exporting to fully understand the archive_serializer_map symbol
 exporting. In this case, let’s again use the Foo class used above.  The
 way the archive_serializer_map is implemented, it is the same as saying
 that all instantiations of the Foo templated class exports symbols when
 compiling Library1, and imports symbols when compiling anything else. This
 causes problems when you instantiate Foo<A> in Library2 and Foo<B> in
 Library3.  In both these cases, the compiler thinks it needs to import the
 symbols for both Foo<A> and Foo<B>, since it is set up to export from
 Library1, and import everywhere else. However, since Foo<A> and Foo<B> are
 being created in different libraries, you actually want Foo<A> to export
 symbols when in Library2, and Foo<B> to export symbols when in Library3.
 The method that I use in the patch achieves this, and allows you to
 specify for each template instantiation of the archive_serializer_map
 whether it’s importing or exporting symbols independently.

 I will admit that this is different from how the rest of boost works, but
 at the same time the rest of boost doesn’t export DLL symbols for
 templated classes, so it will be different no matter what you do. The way
 it’s currently set up, based on what I laid out above, you can only create
 archives in the boost DLL, since it will always export the symbols in the
 boost DLL library and import the symbols in all other libraries regardless
 of where the template is instantiated. My changes in my patch allow you to
 export those symbols in other libraries. If you refuse to change it, then
 you must accept the fact that users will never be able to create their own
 archives when using DLLs. Ever.

 Also, I am wondering why you marked this as “won’t fix”. Your issue was
 with the DLL importing/exporting. While this is necessary if you want to
 create your own archives, there are other aspects of this patch that don’t
 rely on that. The other archive_serializer_map and basic_serializer_map
 changes deal with the serializers being instantiated in multiple
 libraries, which is completely unrelated. Like I said before, please ask
 me if you need clarification for any details, but please don’t close this
 just because you don’t understand it.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/5341#comment:5>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.