[centos7] installation dependency problem: missing libjsoncpp.so.19()(64bit)

I try to install the community edition on a centos 7 system.
Download: core-8.5.81.197_0+27-RHEL_7-x86_64.tar.gz

yum Installation fails with
–> Running transaction check
—> Package kopano-utils.x86_64 0:8.5.81.197-27.1 will be installed
–> Processing Dependency: libjsoncpp.so.19()(64bit) for package: kopano-utils-8.5.81.197-27.1.x86_64

In centos7 there is available /usr/lib64/libjsoncpp.so.0.10.5 from package jsoncpp-0.10.5-2.el7.x86_64.
I cannot find libjsoncpp.so.19

Hi @jj458,

this is a new dependency in our stack and it seems the package was not yet included in the download archive. I just have added the package to the job and it should be included in the next upload.

@fbartels said in [centos7] installation dependency problem: missing libjsoncpp.so.19()(64bit):

this is a new dependency in our stack and it seems the package was not yet included in the download archive. I just have added the package to the job and it should be included in the next upload.

This was still missing in a_aggregates up until now, so it could not possibly have been fixed…

Hi Felix,
could we lower the build-requirements for KC on jsoncpp, too?
As of current, configure.ac is requesting >= 1.4.0 whereas RHEL & Co. are latest on ~0.10.x
++umgfoin.

The build reqiurement is there for a reason - because KC does not build otherwise.
1.4.0 was marked 3 years ago, in Feb 2015.

Hello Jan,
without claim of completeness, current kc-master <7e65052834a> builds well on CentOS6.9 with jsoncpp-devel-0.10.5.

Thank you for solving.
core-8.5.81.224_0+29-RHEL_7-x86_64 is installed successfully in my Centos7 system.

-Joachim

@jj458 said in [centos7] installation dependency problem: missing libjsoncpp.so.19()(64bit):

Thank you for solving.
core-8.5.81.224_0+29-RHEL_7-x86_64 is installed successfully in my Centos7 system.

-Joachim

I initially had looked at the jsoncpp commits. Using git log -p to show all of them, I looked at the last occurrence of “StreamWriterBuilder”, and that turned up in 5fbfe3cdb948a32706ad88635563a41a54819f83, which, when fed to git describe --contains 5fbfe3, gives “1.4.0~20”, so 1.4.0 is the first tag to have SWB.

Checking this again just now, I notice that the SCM history is bonkers – “0.8.0” is a child of “1.4.0”. Which means I cannot request “jsoncpp >= 0.8.0”, because that would satisfy 1.0.0 too, and 1.0.0 is known not to have SWB. What a mess!