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.
If we use json_inttypes.h we are going to fail when builddir != srcdir,
and since JSON_C_HAVE_INTTYPES_H is defined after the configure script
has run, including json_inttypes.h would be the equivalent on including
stdint.h anyway.
This fixes the build of json-c in the GNOME Continuous builder.
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.
Emmanuele Bassi