Lower overhead than opening & reading from /dev/urandom, and works
in chroots and other situtations where /dev/urandom is not available.
Falls back to existing methods when kernel doesn't support the syscall.
With this version script, newly-linked binaries that depend on the
json-c shared library will refer to its symbols in a versioned form,
preventing their references from being resolved to a symbol of the same
name exported by json-glib or libjansson if those libraries appear in
dependency search order before json-c, which will usually result in
a crash. This is necessary because ELF symbol resolution normally uses
a single flat namespace, not a tree like Windows symbol resolution.
At least one symbol (json_object_iter_next()) is exported by all three
JSON libraries.
Linking with -Bsymbolic is not enough to have this effect in all cases,
because -Bsymbolic only affects symbol lookup within a shared object,
for example when json_object_set_serializer() calls
json_object_set_userdata(). It does not affect calls from external
code into json-c, unless json-c was statically linked into the
external caller.
This change will also not prevent code that depends on json-glib or
libjansson from finding json-c's symbols and crashing; to prevent
that, a corresponding change in json-glib or libjansson would be needed.
Adding a symbol-version is a backwards-compatible change, but once
added, removing or changing the symbol-version on a symbol would be an
incompatible change that requires a SONAME bump.
Resolves: https://github.com/json-c/json-c/issues/621
(when combined with an equivalent change to libjansson).
Signed-off-by: Simon McVittie <smcv@collabora.com>
json-c has symbol collisions with other popular C JSON libraries.
To prevent random crashes in downstream applications that may use a
library which depends on json-c, the solution is to statically link
libjson-c.a into those libraries.
`-fPIC`/`-fPIE` is required when building a `.a` so it can be linked
into a `.so`.
The default is now that string data is stored inline at the end of json_object, though to allow for json_object_set_string() to set a _longer_ string, we still need to allow for the possibility of a separate char * pointer.
All json types have been split out now, next step it cleanup.
Using thread-local storage may not be desired in all environments
and/or use-cases, thus there should be an option to disable its use
on purpose.
Fixes#451.
On Windows, or at least when cross-built with Mingw-w64, build fails
because strict prototype fails on an included file (thus nothing we can
do about in json-c code):
> from /home/jehan/dev/src/json-c/json_util.c:44:
> /home/jehan/.local/share/crossroad/roads/w64/json-c/include/minwindef.h:196:3: error: function declaration isn't a prototype [-Werror=strict-prototypes]
> 196 | typedef INT_PTR (WINAPI *FARPROC) ();
> | ^~~~~~~
> /home/jehan/.local/share/crossroad/roads/w64/json-c/include/minwindef.h:197:3: error: function declaration isn't a prototype [-Werror=strict-prototypes]
> 197 | typedef INT_PTR (WINAPI *NEARPROC) ();
> | ^~~~~~~
> /home/jehan/.local/share/crossroad/roads/w64/json-c/include/minwindef.h:198:3: error: function declaration isn't a prototype [-Werror=strict-prototypes]
> 198 | typedef INT_PTR (WINAPI *PROC) ();
> | ^~~~~~~
Let's just disable the errors for Windows build.
Include all compiler warnings, and provide DISABLE_WERROR to make them not be errors.
Define _REENTRANT, if setting it works.
Set -Bsymbolic-functions, and provide DISABLE_BSYMBOLIC to turn that off.
Implement the check for HAS_GNU_WARNING_LONG
