Control: clone -1 -2 -3 Control: retitle -1 json-c: Exports symbols in json_* namespace without symbol-versioning Control: reassign -1 src:json-c 0.13.1+dfsg-9 Control: forwarded -1 https://github.com/json-c/json-c/issues/621 Control: tags -1 + fixed-upstream bullseye sid Control: retitle -2 jansson: Exports symbols in json_* namespace without symbol-versioning Control: reassign -2 src:jansson 2.13.1-1 Control: forwarded -2 https://github.com/akheron/jansson/issues/523 Control: tags -2 + fixed-upstream bullseye sid Control: retitle -3 json-glib: Exports symbols in json_* namespace without symbol-versioning Control: reassign -3 src:json-glib 1.4.4-2 Control: forwarded -3 https://gitlab.gnome.org/GNOME/json-glib/-/issues/33 Control: tags -3 + fixed-upstream bullseye sid
On Sun, 28 Jun 2020 at 22:06:13 +0200, Chris Hofstaedtler wrote: > your libraries BOTH export a symbol named json_object_iter_next, > causing crashes for binaries that end up loading both (possibly > transitively). The agreed-on solution seems to have been to add versioned symbols to each affected library. This is something that needs to be fixed for each of the three libraries separately, so I'm cloning the bug. For the ambiguous resolution of json_object_iter_next() to be resolved, *all three* libraries need to have versioned symbols added (and ideally, dependent libraries and executables should be rebuild against the new versions). Because util-linux (libmount) has taken steps to avoid pulling json-c into unsuspecting processes' namespaces, I don't think this should be treated as RC any more - I think important would now be a more reasonable severity. Chris, do you agree? json-c is using the complicated version of versioned symbols where each symbol is tracked individually, so it is probably a bad idea to backport this change. The first fixed version is 0.15. jansson and json-glib are using a simpler version of versioned symbols where the version of every symbol is the SONAME. Neither has had a release yet. The solution used in jansson and json-glib *might* be acceptable to backport if there is not a suitable upstream release in a reasonable timeframe (although doing things that affect the ABI before they appear in an official upstream release is always risky, and should preferably only be done after consultation with upstream). smcv