#include <string>
#include <s11n.net/s11n/s11n_config.hpp>
#include <s11n.net/s11n/classload.hpp>
#include <s11n.net/s11n/traits.hpp>
#include <s11n.net/s11n/exception.hpp>
#include <s11n.net/s11n/serialize.hpp>
#include <s11n.net/s11n/algo.hpp>
#include <s11n.net/s11n/s11n_node.hpp>
Go to the source code of this file.
Namespaces | |
namespace | s11n |
namespace | s11n::Private |
namespace | s11n::io |
namespace | s11n::Detail |
Defines | |
#define | s11n_S11N_H_INCLUDED 1 |
Functions | |
std::string | library_version () |
Returns the string form of the s11n library version. | |
void | s11n_1_1_assertion () |
Internal, not for client use. |
|
|
|
Returns the string form of the s11n library version.
|
|
Internal, not for client use. Adds a symbol which is checked by s11nconvert, so that s11nconvert will not link against an s11n 1.0 library. The problem is that the 1.1 s11nconvert can build using the 1.1 s11n headers and link to the 1.0 lib, resulting in segfaults at runtime instead of a link error. This symbol is only to work around that, and it does not perform any operations. It won't necessarily trigger a link error until s11nconvert is actually run, in which case dynamic linking will fail (as expected). e.g., the following binary is inadvertently linked to the 1.0 lib:
stephan:~/cvs/s11n.net/1.1/s11n/src/client/s11nconvert> ldd s11nconvert ... libs11n.so.1 => /home/stephan/lib/libs11n.so.1 (0x40019000) ... libs11n_zfstream.so.2004 => /home/stephan/lib/libs11n_zfstream.so.2004 (0x4026e000) libs11n_stringutil.so.2004 => /home/stephan/lib/libs11n_stringutil.so.2004 (0x40279000) libs11n_class_loader.so.2005 => /home/stephan/lib/libs11n_class_loader.so.2005 (0x40281000) ... libs11n_acme.so.2005 => /home/stephan/lib/libs11n_acme.so.2005 (0x402b5000) ... So we force it fail at link-time by simply linking against a symbol we know isn't in the 1.0 library:
stephan:~/cvs/s11n.net/1.1/s11n/src/client/s11nconvert> ./s11nconvert ./s11nconvert: symbol lookup error: ./s11nconvert: undefined symbol: _ZN4s11n7Private18s11n_1_1_assertionEv In any case, this is a lame kludge and will go away someday. |