Re: [Boost-users] [EXTERNAL] Re: [MPI] missing symbols using serialization's static library design

17 Oct 2012

      Barrett, Brian W wrote:
...
On 10/13/12 1:09 AM, "Robert Ramey"  wrote:
...
Barrett, Brian W wrote:
...
While I could simply explicitly insatiate the missing archivers,
that seems like a bad idea for something in the detail namespace
and it appears that the list of archivers I'd need to instantiate
has changed over time. Is there a better solution to the problem?
There's a test case the exhibits the problem available here on our
Google code project bug tracker.  It's essentially the
Boost.Serialization demo_pimpl example, but using MPI instead of a
text archiver.  The code is at:
hmmm: couldn't find it.

 It was always a disappointment to me that we couldn
test the MPI serialization in the same way all the other archive
types are tested.  That is, if understand correctly, we can't just
dropin the mpi_?archive into the tests and run tem all.
...
...
I'm guessing that one will need to explicitly initialilze some stuff
in the
mpi archives static library.
This is done for the other serialization static libraries.  I would
compare
the mpi serialization
build against the other archive build and see which, if any explicit
instantiations are
in one but not the other.
I know how to determine which MPI archivers need to be explicitly
instantiated, but as I said, that's a rather unsatisfying answer to
the problem.  It appears that the list of archivers I have to
explicitly instantiate has changed along the way from Boost 1.43.0
(the version that was current when we started the project) and Boost
1.51.0.  At least one of the archivers is in the detail namespace, so
the authors clearly believe such details are internal to the
implementation.  This puts us in a rather large support bind.  I was
hoping that there would be a better way (like a macro to help with
the explicit instantiation or something similar.
How about suggesting a patch to the MPI serialization inplementation
which would sync this implementation up with the others.

BTW -
...
Brian