When releasing libzim and libkiwix, we use config native_mixed with is a mix of static and dynamic linking:
Dependencies are build as static libraries.
Released projects (libzim/libkiwix) are build as dynamic libraries, statically linked to dependencies.
This way, we have only one .so file which contain all our needed symbols.
However, this logic is "local" to each project.
This mean that libkiwix is linked statically to libzim. So libkiwix.so is containing libzim symbols.
But on "java-libkiwix", we are both linking to libzim.so and libkiwix.so. If the version of the (dynamically) used libzim.so is not the same that the version on which we have (statically) linked libkiwix.so, we end with symbols of two different versions being loaded and conflicting.
So let's rebuild libkiwix with last version of libzim to avoid this conflict.
Note this is not a API nor ABI break issue. It is a compilation issue because we do some funky things.
When releasing libzim and libkiwix, we use config native_mixed with is a mix of static and dynamic linking:
This way, we have only one
.sofile which contain all our needed symbols.However, this logic is "local" to each project. This mean that libkiwix is linked statically to libzim. So libkiwix.so is containing libzim symbols.
But on "java-libkiwix", we are both linking to libzim.so and libkiwix.so. If the version of the (dynamically) used libzim.so is not the same that the version on which we have (statically) linked libkiwix.so, we end with symbols of two different versions being loaded and conflicting.
So let's rebuild libkiwix with last version of libzim to avoid this conflict.
Note this is not a API nor ABI break issue. It is a compilation issue because we do some funky things.