this is a public announcement.
if you link against PulseAudio, whether you want it or not, you’ll get an
automatic dependency on json-c, a small C library that parses JSON and
doesn’t have any dependency1. sadly, json-c leaks symbols all over the
place, and one of them is called json_object_get_type()2.
JSON-GLib, the library that yours truly wrote about 6 years ago to parse
JSON using a decent C library as a base, also has a type called
json_object_get_type()3.
if you link against PulseAudio and JSON-GLib4 then you’ll get a segmentation fault with a weird stack trace, like this one and its duplicates5.
the solution is to depend on a version of JSON-GLib greater than 0.16.1,
which builds JSON-GLib with the -Bsymbolic linker flag6.
that would be all.
-
which is arguably a plus for a system dæmon ↩
-
which returns an integer for I don’t know which reason ↩
-
which returns a
GTypefor theJsonObjectboxed structure, so you can use them in properties and signal marshallers; as it happens,GTypeis alonglook-alike ↩ -
or any other library that depends on JSON-GLib, like Clutter ↩
-
since both return values and arguments of the functions above are compatible, the linker won’t moan about it, so you won’t see any warning or error when building your code ↩
-
another solution is to statically link json-c inside PulseAudio instead of dynamically linking it; another solution is to link json-c with
-Bsymbolic; yet another solution would be for PA to not use a dependency to parse JSON – or drop JSON entirely because I can’t for the life of me understand why an audio server is dealing with JSON at all ↩