2016-04-01 14:48 GMT+02:00 Michael Biebl <[email protected]>: > 2016-04-01 14:33 GMT+02:00 Rainer Gerhards <[email protected]>: >> 2016-03-31 18:38 GMT+02:00 Michael Biebl <[email protected]>: >>> This affects the packages in sid as well, which are currently stuck at >>> 8.16.0. >>> One aspect I particularly don't like about the libfastjson/json-c fork >>> is, that the old namespace was kept. >>> This can become tricky once libjson-c and libfastjson are loaded into >>> the same process space. This can lead to unexpected behaviour. > > Obviously, this only poses a problem if the ABI changes in > incompatible ways, like the type signature of a function. > >> You are absolutely right, I did not completely think this through and >> screwed up in this regard. I need to move json-c compatibility to >> source level (via CPP macros), if at all required. Changing the native >> API from json_* to fjson_* is on my todo list, and probably it's a >> good time to initiate this now. > > Either we rename it, or we promise to never break ABI compatibility > with json-c. The former is more work initially, but gives you more > freedom going onwards. > The latter is possible too, see libjpeg (from IJG) and libjpeg-turbo. > But it needs very careful maintenance of the library.
Renaming is the right thing to do. A core reason for the fork is that we have other needs than the json-c community. One of things that I explicitly mentioned is that we need some API breaks - e.g. for NUL byte handling and to get rid of things that I really don't consider part of the API (like the hashtable functions) and would like to get rid of. Also, lots of internals will need to change in the longer term, so there will be visible differences. Note that I originally intended to work on that area later this year (summer?), but were forced to do it urgently when the multithreading bug came up. So what I have now is an "emergency release" (thus the 0.99 number). Again, I didn't see any way around this. Even if we had assumed json-c would have accepted a PR to fix the issue, they would not have done a release (cycle seems to be 1..2 years per release), and even if they had done so, distros would still ship lots of old releases (as they do now). So the only way to solve this situation IMHO is to require current rsyslog to force a fixed json-c version (aka libfastjson in that regard). Even if that comes at the price that distros won't go past 8.16, but at least users then know why it segfaults and have a path forward (building from source or using our packages when available). Rainer > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of > sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T > LIKE THAT. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
