While packaging jansson for Solaris we found out that the use of atomic operations complicates things. The configure script detects what kind of atomic implementation is available. Either _atomic , or _sync or none. It records the outcome as defined/undefined macros JSON_HAVE_ATOMIC_BUILTINS / JSON_HAVE_ATOMIC_BUILTINS and defines JSON_INTERNAL_INCREF / JSON_INTERNAL_DECREF accordingly in jansson_config.h. And starts to use the atomic functions internally in function json_incref / json_decref.
The problem is that it silently expects that the consumer will be able to use the same atomic primitives. That might easily not be the case if you use different compiler and/or you are forced to use C89 standard.
There are two workarounds
make every consumer undefine JSON_HAVE_ATOMIC_BUILTINS / JSON_HAVE_SYNC_BUILTINS to make the consumer not use atomics at all
patch jansson sources to remove atomic support.
Would it perhaps make more sense to make json_incref / json_decref a real functions (exported by the dynamic library) instead of having them as macros as they are now?
Hi,
While packaging jansson for Solaris we found out that the use of atomic operations complicates things. The configure script detects what kind of atomic implementation is available. Either _atomic , or _sync or none. It records the outcome as defined/undefined macros JSON_HAVE_ATOMIC_BUILTINS / JSON_HAVE_ATOMIC_BUILTINS and defines JSON_INTERNAL_INCREF / JSON_INTERNAL_DECREF accordingly in jansson_config.h. And starts to use the atomic functions internally in function json_incref / json_decref.
The problem is that it silently expects that the consumer will be able to use the same atomic primitives. That might easily not be the case if you use different compiler and/or you are forced to use C89 standard.
There are two workarounds
Would it perhaps make more sense to make json_incref / json_decref a real functions (exported by the dynamic library) instead of having them as macros as they are now?
Thank you