Bug 1123785 - json-c has API changes without soname bump
Summary: json-c has API changes without soname bump
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: json-c
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Christopher Meng
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-28 09:14 UTC by Sandro Mani
Modified: 2015-02-17 09:55 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-17 09:55:06 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1129292 None None None Never

Internal Links: 1129292

Description Sandro Mani 2014-07-28 09:14:34 UTC
Description of problem:
I.e.: could not load library "/usr/lib64/pgsql/postgis-2.1.so": /usr/lib64/pgsql/postgis-2.1.so: undefined symbol: json_tokener_errors

Version-Release number of selected component (if applicable):
json-c-0.12-2.fc22.x86_64

Comment 1 Christopher Meng 2014-07-28 09:51:58 UTC
I will forward this to the upstream to tell this problem.

And, have you requested a rebuild of postgis to see if it still exists?

Comment 2 Sandro Mani 2014-07-28 09:54:22 UTC
postgis does not build against the new json-c due to the API changes. I think the first priority is bumping the soname so that all packages with broken dependencies get caught. In particular, for stable releases, the update should get unpushed.

Comment 3 Christopher Meng 2014-07-28 10:57:43 UTC
Per upstream changelog, function json_tokener_error_desc() should be its replacement. I will modify the Makefile tomorrow to bump the soname.

I'm starting the checkup to see how many packages affected, 1 confirm unaffected: zmap.

[tinga@fab hhvm]$ readelf -Ws /usr/sbin/zmap | grep json
    15: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_new_array
    16: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_to_json_string
    17: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_new_string
    30: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_array_add
    33: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_new_object
    57: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_new_int
    67: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_object_add
    92: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_new_double
   118: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_new_int64
   124: 00000000     0 FUNC    GLOBAL DEFAULT  UND json_object_put
   207: 080708a0    32 OBJECT  GLOBAL DEFAULT   24 module_json_file
   223: 080600c0  1537 FUNC    GLOBAL DEFAULT   13 json_output_file_init
   244: 0805fe00   597 FUNC    GLOBAL DEFAULT   13 json_output_file_ip
   365: 08060060    86 FUNC    GLOBAL DEFAULT   13 json_output_file_close

In progress...

Comment 4 Christopher Meng 2014-07-28 12:56:03 UTC
Bumped:

json-c-0.12-3.fc22

json-c-0.12-3.fc21

Comment 5 Sandro Mani 2014-07-28 12:58:07 UTC
Thank you

Comment 6 Michael Schwendt 2014-07-28 13:37:56 UTC
This could have been avoided by using basic tools, such as rpmsodiff (or abi-compliance-checker), more often than not during version upgrades.


> +# Bump the soname manually.
> +sed -i 's#2:1:0#3:0:0#' Makefile.am

Has this been acknowledged by the upstream developers? If you bump soname versions on your own, that bears several risks.

Comment 7 Remi Collet 2014-07-28 13:42:02 UTC
Bumping soname without upstream acknowledgment seems a very bad idea (what will you do when upstream will really bump soname ?)


I really prefer we keep 0.11 for now (at least in Fedora 21).


More: this update breaks php-pecl-jsonc (lot of test are now "failed")

We already have lot of people crying because of minor behavior change
between ext/json (non-free) and pecl/jsonc, introducing some other is
juste a very bad idea.

My goal is to fork the json-c parser, bundled it in pecl/jsonc (yes !)
and adapt it to optimize parser time and fix difference with ext.json

But this is a long road and probably not in a very short time.

Comment 8 Christopher Meng 2014-07-29 01:39:37 UTC
(In reply to Remi Collet from comment #7)
> Bumping soname without upstream acknowledgment seems a very bad idea (what
> will you do when upstream will really bump soname ?)
> 
> 
> I really prefer we keep 0.11 for now (at least in Fedora 21).
> 
> 
> More: this update breaks php-pecl-jsonc (lot of test are now "failed")

Is it OK for you to port your code to 0.12? Schedule?

> We already have lot of people crying because of minor behavior change
> between ext/json (non-free) and pecl/jsonc, introducing some other is
> juste a very bad idea.
> 
> My goal is to fork the json-c parser, bundled it in pecl/jsonc (yes !)
> and adapt it to optimize parser time and fix difference with ext.json
> 
> But this is a long road and probably not in a very short time.

Yes I understand. I just spent 2 hours reading your code.

Comment 9 Remi Collet 2014-07-29 05:30:59 UTC
(In reply to Christopher Meng from comment #8)
> > More: this update breaks php-pecl-jsonc (lot of test are now "failed")
> 
> Is it OK for you to port your code to 0.12? Schedule?

Not planed.

Comment 10 Colin Walters 2014-07-29 17:08:20 UTC
External issue appears to be:

https://github.com/json-c/json-c/issues/147

Comment 11 Christopher Meng 2015-02-17 09:55:06 UTC
All packages should have been fixed.

Upstream is still keeping silent on the soname bump, I have no idea.


Note You need to log in before you can comment on or make changes to this bug.