EXTRA_DIST copies the listed directories/files from the _source_ directory
into the distribution.
Since the doc directory does not exist after running autogen + configure
+ make dist, the distribution tarball generation fails.
Note that the dist-hook rule below operates on 'distdir', not on the source
directory where EXTRA_DIST expects the existence of the doc folder.
In summary, even if I removed 'doc' from EXTRA_DIST, the dist tarball will
always contain the documentation (due to the dist-hook rule).
Signed-off-by: László Várady <laszlo.varady@balabit.com>
If we want to override `strerror()` in libjson-c
to make tests consistent across platforms, we
need to do it build-wide as configure/build
option.
Apple linkers make it really hard to override functions
at link-time, and this seems to be locked down on travis-ci.org
[ for security reasons I assume ].
While I got it to work locally, it did not work
when running on travis.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This reverts commit aaba8c1080.
This commit breaks builddir != srcdir build, but, more importantly, it
also adds a dependency on a header, "config.h", which is not installed
and it's supposed to be private — since it's generated at configuration
time and it's not meant to be used by projects compiling against a
library.
The -Bsymbolic-functions linker flag reduces the amount of PLT jumps in
a shared object, and has a side effect of preventing symbol collisions
in libraries and applications linking against two different shared
objects exposing the same symbol.
While the former is (generally) a performance win, the latter is less
rare than expected. For instance, PulseAudio started linking against
json-c a while ago; now, every project linking against PulseAudio is
leaking json-c symbols. In the GNOME platform, this means that projects
linking against PulseAudio cannot be safely linked against other
libraries depending on the GLib-based JSON parsing libraries JSON-GLib,
because of a symbol conflict. Nominally, this conflict would not be an
issue: libraries and applications do not need to depend on two different
JSON parsing libraries; the symbol leakage, though, ends up causing
either segmentation faults, or weird errors. For further reference,
please see: https://bugzilla.gnome.org/show_bug.cgi?id=703734
JSON-GLib already switched to using -Bsymbolic-functions, but it would
be safe if json-c did the same, wherever the linker flag is available.
Changing root name of library to json-c, and also the
directory where header files are installed to .../jsdon-c/*.
This avoids clashes with other implementations of JSON libraries.
As part of this create a public json_config.h with a custom define to
decide whether to include inttypes.h to avoid conflicting with other
projects config.h header.
Brent Cook
Eric Haszlakiewicz
László Várady
Alexandru Ardelean
Emmanuele Bassi
Nicola Spanti (RyDroid)
Christopher Meng
Michael Clark
Alexander Klauer
Arun Raghavan
Keith Derrick
Martin Storsjo