This flag used on xapian-meson build on Windows ends in a crash in
libzim when compacting the database.
To be fixed at a moment but let's not use this flag for now on Windows
The meson build fails on cross compiliation `win32_*` and
on `native_dyn` on Macos (but doesn't fail on `native_static` or
`native_mixed`...)
On top of that, the fact that xapian-meson build system is fluky on
Windows doesn't make me confident.
As I will be out for few months, I prefer keep the autotool build system
on already working configs.
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.
This reverts commit 05fc3b409c.
This was a temporary commit to make the PR compile with a dev branch of libzim.
Now PR on libzim is merged. We must remove this commit.
- Archive already existing must not stop download of other archives.
- Use copytree instead of rename to use second archive as patch on existing
directory. (No need to remove tmpdir, as it is a temporary directory)
Job `Trigger_Docker` is run in a simple environment not configured.
So tools as `ninja` are not installed. But we don't care as we just want
to trigger a docker build.
But `common` script now start by asking kiwix-build the build dir.
kiwix-build must not fail in this case.
