ulib/3party/jsoncpp/example
tqcq 585bca14e3
Some checks failed
rpcrypto-build / build (Debug, himix200.toolchain.cmake) (push) Successful in 50s
rpcrypto-build / build (Release, himix200.toolchain.cmake) (push) Successful in 54s
linux-x64-gcc / linux-gcc (push) Successful in 58s
rpcrypto-build / build (Release, hisiv510.toolchain.cmake) (push) Successful in 1m5s
linux-mips64-gcc / linux-gcc-mips64el (push) Successful in 1m21s
rpcrypto-build / build (Debug, hisiv510.toolchain.cmake) (push) Successful in 1m7s
linux-hisiv500-gcc / linux-gcc-hisiv500 (push) Failing after 46s
feat add jsoncpp
2023-12-26 20:58:36 +08:00
..
readFromStream feat add jsoncpp 2023-12-26 20:58:36 +08:00
readFromString feat add jsoncpp 2023-12-26 20:58:36 +08:00
streamWrite feat add jsoncpp 2023-12-26 20:58:36 +08:00
stringWrite feat add jsoncpp 2023-12-26 20:58:36 +08:00
CMakeLists.txt feat add jsoncpp 2023-12-26 20:58:36 +08:00
README.md feat add jsoncpp 2023-12-26 20:58:36 +08:00

NOTE

If you get linker errors about undefined references to symbols that involve types in the std::__cxx11 namespace or the tag [abi:cxx11] then it probably indicates that you are trying to link together object files that were compiled with different values for the _GLIBCXX_USE_CXX11_ABI marco. This commonly happens when linking to a third-party library that was compiled with an older version of GCC. If the third-party library cannot be rebuilt with the new ABI, then you need to recompile your code with the old ABI,just like: g++ stringWrite.cpp -ljsoncpp -std=c++11 -D_GLIBCXX_USE_CXX11_ABI=0 -o stringWrite

Not all of uses of the new ABI will cause changes in symbol names, for example a class with a std::string member variable will have the same mangled name whether compiled with the older or new ABI. In order to detect such problems, the new types and functions are annotated with the abi_tag attribute, allowing the compiler to warn about potential ABI incompatibilities in code using them. Those warnings can be enabled with the -Wabi-tag option.