[serialization] autolinking
I'd like to know which the circumstances are under which Boost.Serialization autolinking feature kicks in. Last time I discuseed with Robert about this (see http://lists.boost.org/MailArchives/boost/msg78596.php) seemed that autolinking won't affect programs that are only including boost/serialization/* headers but *not* including any of *_?archive.hpp. But recent tests in the mslater regression runner (for instance http://tinyurl.com/a3n6u) suggest that this may not longer be true. Clarification, please? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Hmm - I just made a "correction" regarding auto-linking to make things work better with my VC 7.1 IDE. I noticed this issue in the test matrix as well. I'm still looking into it. Robert Ramey JOAQUIN LOPEZ MU?Z wrote:
I'd like to know which the circumstances are under which Boost.Serialization autolinking feature kicks in.
Last time I discuseed with Robert about this (see http://lists.boost.org/MailArchives/boost/msg78596.php) seemed that autolinking won't affect programs that are only including boost/serialization/* headers but *not* including any of *_?archive.hpp. But recent tests in the mslater regression runner (for instance http://tinyurl.com/a3n6u) suggest that this may not longer be true. Clarification, please? Thank you,
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I've looked at this a tiny bit. Here are the facts as I understand them a) According to www.boost.org/more/separate_compilation.html Autolinking will be enabled only if BOOST_ALL_NO_LIB and BOOST_SERIALIZATION_NO_LIB are not defined. The auto link code in the serialization library is written to conform to this b) Two platforms - MSVC and VC7 - fail to link for lack of libraries whose name signatures suggest auto-linking is enabed during compilation. That is neither of the two macros above seems to be defined. c) Other platforms which implement autolinking - VC 7.1, VC 8.0, Borland and CW don't seem to have any problems linking. So I believe there is some issue re autolink with these particular compilers. It may be an error in the serialization library or some compiler/preprocessor quirk. I went back to the posts referenced and at this point don't doubt my original conclusions. Robert Ramey JOAQUIN LOPEZ MU?Z wrote:
I'd like to know which the circumstances are under which Boost.Serialization autolinking feature kicks in.
Last time I discuseed with Robert about this (see http://lists.boost.org/MailArchives/boost/msg78596.php) seemed that autolinking won't affect programs that are only including boost/serialization/* headers but *not* including any of *_?archive.hpp. But recent tests in the mslater regression runner (for instance http://tinyurl.com/a3n6u) suggest that this may not longer be true. Clarification, please? Thank you,
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
c) Other platforms which implement autolinking - VC 7.1, VC 8.0, Borland and CW don't seem to have any problems linking.
Actually CW is currently having problems with autolinking in regard to the libraries produced by Boost.Build. You can see it in the messages put out by the linker, for example: ### mwld Linker Warning: # Cannot locate library "libboost_serialization-cw8-mt-sgd-1_33" specified in #pragma comment(lib,...) http://engineering.meta-comm.com/boost-regression/cvs-head/developer/output/... http://tinyurl.com/aw9j2 But this is do to a discrepancy between Boost.Build and the autolink code. I'm adjusting Boost.Build in this case as CW does maintain link compatibility in major versions. Just and FYI ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Robert Ramey ha escrito:
I've looked at this a tiny bit. Here are the facts as I understand them
a) According to www.boost.org/more/separate_compilation.html Autolinking will be enabled only if BOOST_ALL_NO_LIB and BOOST_SERIALIZATION_NO_LIB are not defined. The auto link code in the serialization library is written to conform to this
This is correct.
b) Two platforms - MSVC and VC7 - fail to link for lack of libraries whose name signatures suggest auto-linking is enabed during compilation. That is neither of the two macros above seems to be defined.
I can confirm this; I've just checked it out in MSVC++ 6.0 against the latest code in the CVS, and just about any piece of code involving Boost.Serialization triggers autolinking by default (i.e. if the inhibiting macros are not defined.)
c) Other platforms which implement autolinking - VC 7.1, VC 8.0, Borland and CW don't seem to have any problems linking.
So I believe there is some issue re autolink with these particular compilers. It may be an error in the serialization library or some compiler/preprocessor quirk.
I went back to the posts referenced and at this point don't doubt my original conclusions.
I humbly request that you reconsider your design so that the following guarantee is honored: * (A) Any code including *only* boost/serialization/*.hpp headers won't trigger autolinking of Boost.Serialization. The following is a rationale for this policy: a 3rd party library that provides *intrusive* serialization capabilities will most likely need to include some of boost/serialization/*.hpp. If those headers trigger autolinking, the user will face the annoying fact that Boost.Serialization is autolinked even if she didn't explicitly try to use serialization at all. Granted, if the serialization capabilities of the 3rd party library are not taking advantge of, autolinking will ultimately have no effect on the final binary, but the point is that the user will be forced nonetheless to have the Boost.Serialization lib built and available. This is most unfortunate in the case the 3rd party library is a header-only lib, since the user may very well be using it without having built anything from Boost. This is exactly what's happening now with Boost.MultiIndex. Autolinking is triggered by the (implicit) inclusion of boost/serialization/config.hpp. This header is in turn included by void_cast.hpp and extended_type_info.hpp, and if you pull out from this thread it turns out virtually any boost/serialization/*.hpp header will trigger autolinking. To honor (A), you just have to remove the inclusion of boost/serialization/config.hpp by the aforementioned void_cast.hpp and extended_type_info.hpp. From what I can see, the inclusion is done so as to bring in the definition of BOOST_SERIALIZATION_DECL, so in principle having this macro defined in a separate header would suffice. If (A) is honored, autolinking will be triggered only when including boost/archive/*.hpp headers, which IMHO is just fine, since these are a sure sign that the user (not the 3rd party library) is explicitly requesting serialization capabilities and will welcome the autolinking stuff. Hope this helps a little. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz ha escrito:
I humbly request that you reconsider your design so that the following guarantee is honored:
* (A) Any code including *only* boost/serialization/*.hpp headers won't trigger autolinking of Boost.Serialization.
The following is a rationale for this policy: a 3rd party library that provides *intrusive* serialization capabilities will most likely need to include some of boost/serialization/*.hpp. If those headers trigger autolinking, the user will face the annoying fact that Boost.Serialization is autolinked even if she didn't explicitly try to use serialization at all. Granted, if the serialization capabilities of the 3rd party library are not taking advantge of, autolinking will ultimately have no effect on the final binary, but the point is that the user will be forced nonetheless to have the Boost.Serialization lib built and available. This is most unfortunate in the case the 3rd party library is a header-only lib, since the user may very well be using it without having built anything from Boost. This is exactly what's happening now with Boost.MultiIndex.
Autolinking is triggered by the (implicit) inclusion of boost/serialization/config.hpp. This header is in turn included by void_cast.hpp and extended_type_info.hpp, and if you pull out from this thread it turns out virtually any boost/serialization/*.hpp header will trigger autolinking. To honor (A), you just have to remove the inclusion of boost/serialization/config.hpp by the aforementioned void_cast.hpp and extended_type_info.hpp. From what I can see, the inclusion is done so as to bring in the definition of BOOST_SERIALIZATION_DECL, so in principle having this macro defined in a separate header would suffice.
I have inspected the source code and looks like autolinking is triggered in three points: boost/serialization/config.hpp boost/archive/detail/auto_link_archive.hpp boost/archive/detail/auto_link_warchive.hpp So, it seems like my proposal boils down to removing autolinking from the first header. As a proof of concept, I've done so (see attached modified source); with this changes in place, my local tests seem to indicate that: * Autolinking does not kick in if including only boost/serialization/*.hpp headers. * Autolinking still works if including any of boost/archive/*.hpp. boost/serialization/config.hpp has a local macro named IMPORT whose semantics escapes me, so I might be missing something. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (4)
-
JOAQUIN LOPEZ MU?Z -
Joaquín Mª López Muñoz
-
Rene Rivera -
Robert Ramey