The output of snprintf might produce ',' separators for decimal places if
certain locales are set. This commit moves the converversion from ',' to '.'
to correct place. Otherwise an additional ".0" might be appended.
/root/firefox-gcc-last/toolkit/components/jsoncpp/src/lib_json/json_writer.cpp:139:16: note: using the range [-2147483648, 2147483647] for directive argument
/root/firefox-gcc-last/toolkit/components/jsoncpp/src/lib_json/json_writer.cpp:146:10: note: 'sprintf' output between 5 and 15 bytes into a destination of size 6
sprintf(formatString, "%%.%dg", precision);
~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Google advises its employees to add Google Inc. as an author, but that hasn't
been done yet and would be super inconvenient. So instead I've refactored the
file to refer to "The JsonCpp Authors", which are listed in the AUTHORS file.
The AUTHORS file itself is generated via:
git log --pretty="%an <%ae>%n%cn <%ce>" | sort | uniq
Plus the addition of "Google Inc." as a copyright author. (Google owns the work
of anyone contributing from an @google.com address, for example.)
The list contains some probable duplicates where people have used more than one
email address. I didn't deduplicate because -- well, who's to say they're
duplicates, anyway? :)
Using full paths is more versatile. The current solution
breaks when specifying an absolute path for CMAKE_INSTALL_INCLUDEDIR
which is an otherwise supported option by CMake's GNUInstallDirs.
CMake does not support Autoconf-style ${prefix}-pseudo variables,
hence trying to emulate the behaviour gains us nothing and breaks
providing absolute paths to CMAKE_INSTALL_LIBDIR.
Plus some other build-related changes. I don't think there is anything
functionally different from 1.7.7, or even any binary incompatibilities, but
the cmake change is significant.
* The GNUInstallDirs module is more idiomatic and supported by
Kitware upstream, whereas the current directories are not
standardised across CMake-using packages. Using CMake native
mechanisms is better than reinventing the wheel, as it makes
using the build system more uniform across the ecosystem
* Use CMAKE_CXX_STANDARD to force C++11
* Require CMake 3.1.0 at a minimum
* Fixed lower/UPPERcase format for function/macro calls
* Fixed indents by replacing tabs with 4 spaces
Removed a static variable used to contain the current recursion depth of Reader::readValue(). The number of elements in an internal container Reader::nodes_ is used instead. It is correct because any recursive call of Reader::readValue() is executed with adjacent nodes_.push() and nodes_.pop() calls.
Added the option to change the allowed recursion depth at compile time by defining a macro JSONCPP_STACK_LIMIT as the required integer value.
Rename variable empty to emptyString in Value constructor to avoid shadowing of Value::empty().
GCC 4.8 produces the warning about this:
lib_json/json_value.cpp: In constructor ‘Json::Value::Value(Json::ValueType)’:
lib_json/json_value.cpp:346:27: warning: declaration of ‘empty’ shadows a member of 'this' [-Wshadow]
Otherwise failures like these one can happen during the configure phase
of other applications that use jsoncpp, like upmpdcli for instance:
checking jsoncpp/json/json.h usability... yes
checking jsoncpp/json/json.h presence... yes
checking for jsoncpp/json/json.h... yes
configure: error: libjsoncpp not found.
And this is the actual problem that you can see in config.log:
configure:5233: checking for jsoncpp/json/json.h
configure:5233: result: yes
configure:5259: /usr/bin/mipsel-linux-g++ -o conftest conftest.cpp
-lmicrohttpd -lmpdclient -lpthread -ljsoncpp >&5
In file included from /usr/include/jsoncpp/json/autolink.h:9:0,
from /usr/include/jsoncpp/json/json.h:9,
from conftest.cpp:26:
/usr/include/jsoncpp/json/config.h:155:9: error: 'int64_t' does not name
a type
typedef int64_t Int64;
^
/usr/include/jsoncpp/json/config.h:156:9: error: 'uint64_t' does not
name a type
typedef uint64_t UInt64;
^
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Recent commit 911e2b0fea ("By default use <prefix> relative paths when
installing") introduced relative install paths in CMake. But this
interacts badly with commit e6f1cffdd3 from a year ago: now, the paths in
`pkgconfig/jsoncpp.pc` are relative, which is incorrect.
Before 911e2b0fea (1.7.2 on Archlinux), this was correct:
$ head -4 /usr/lib/pkgconfig/jsoncpp.pc
prefix=/usr
exec_prefix=${prefix}
libdir=/usr/lib
includedir=/usr/include
After 911e2b0fea (1.7.3 on Archlinux), this is now incorrect:
$ head -4 /usr/lib/pkgconfig/jsoncpp.pc
prefix=/usr
exec_prefix=${prefix}
libdir=lib
includedir=include
This change causes hard-to-debug compilation errors for projects that
depend on jsoncpp, for instance:
CXXLD libring.la
/tmp/ring-daemon/src/ring-daemon/src/../libtool: line 7486: cd: lib: No such file or directory
libtool: error: cannot determine absolute directory name of 'lib'
make[3]: *** [Makefile:679: libring.la] Error 1
This is because jsoncpp contributes `-Llib -ljsoncpp` to the LDFLAGS, via
the pkg-config machinery. Notice the relative path in `-Llib`.
To fix this, simply revert commit e6f1cffdd3 ("Fix custom includedir &
libdir substitution in pkg-config"). The change in 911e2b0fea should have
the same effect.
See #279, #470 for references.
