This commit fixes the following build issue of libfastjson with old
enough compilers (4.8) and wchar disabled:
json_object.c: In function 'fjson_object_object_delete':
json_object.c:385:3: error: 'for' loop initial declarations are only allowed in C99 mode
for (int i = 0 ; i < FJSON_OBJECT_CHLD_PG_SIZE ; ++i) {
^
The code of libfastjson requires C99. If your compiler is recent
enough (gcc 5.x), then no problem, it is C99 by default, no additional
flags are needed.
If your compiler is older (for example gcc 4.8), then -std=c99 or
-std=gnu99 is explicitly needed to tell the compiler to accept C99
constructs. Testing the compiler for the availability of such flags is
done by libfastjson configure script. However, the test program used
by the configure script uses some wchar_t types, and therefore the
test checking for C99 availability fails on toolchains with wchar
disabled. From config.log:
configure:3928: checking for /home/test/buildroot/output/host/usr/bin/i586-buildroot-linux-uclibc-gcc option to accept ISO C99
[...]
configure:4077: /home/test/buildroot/output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -std=gnu99 -c -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 conftest.c >&5
conftest.c:54:3: error: unknown type name 'wchar_t'
const wchar_t *name;
^
So, just like we did in libv4l in commit
f01396a158 ("libv4l: fix uclibc-ng
configure/compile"), let's hint directly the configure script that it
should use -std=gnu99. This fixes the build of libfastjson with old
compilers and wchar disabled.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The check-package script when ran gives warnings on text wrapping
on all of these Config files. This patch cleans up all warnings
related to the text wrapping for the Config files starting with
lib in the package directory.
The appropriate indentation is: <tab><2 spaces><62 chars>
See http://nightly.buildroot.org/#writing-rules-config-in for more
information.
Signed-off-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When atomic intrisics are missing, libfastjson falls back to using
pthread mutexes to manage atomicity. Of course, this is much less
efficient than atomics, but it does the job.
Propagate the new dependency to rsyslog, the sole user of libfastjson.
Note: rsyslog already depends on threads for itself, but we believe it
is better to have the exact same dependency propagated.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libfastjson is supposed to use the __sync_*4 atomic intrinsics, but alas
it is not using them because their ./configure decides they are not
available: it uses AC_TRY_RUN to check for them, and the default is to
decide they are not available, because of cross-compilation.
Besides, one of the source files was not including the generated
config.h, so even after fixing ./configure there was still a build
error.
The first patch is a backport from upstream to fix the missing
inclusion.
The second patch is switching AC_TRY_RUN over to AC_LINK_IFELSE, as the
only thing we're interested in is to check for the presence of the
atomic intrisics, and linking is enough for that.
Fixes:
http://autobuild.buildroot.org/results/192/1923d0b570adba494f83747a9610ea6ec35f5223/http://autobuild.buildroot.org/results/23a/23ac0e742ed3a70ae4d038f8c9eadc23e708f671/
and many others...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Libfastjson is a fork of json-c, and a dependency of newer versions of
rsyslog.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
