Windows cross-build of libzip 1.4.0 fails,
Re: Windows cross-build of libzip 1.4.0 fails,
- Re: Windows cross-build of libzip 1.4.0 fails, Lubomir I. Ivanov (2018/01/07 19:11:31)
- Re: Windows cross-build of libzip 1.4.0 fails, Thomas Klausner (2018/01/07 19:00:38)
Hello Benjamin! On Sun, Jan 07, 2018 at 12:46:00AM -0800, Benjamin Gilbert wrote: > libzip 1.4.0 has several problems cross-building for Windows from Linux > with MinGW-w64: > > 1. regress/malloc.c #includes dlfcn.h, which doesn't exist on Windows. The > Autotools infrastructure did not attempt to build malloc.c on Windows, but > regress/CMakeLists.txt does not appear to contain any such exclusion. We're not currently using this, so I've unhooked it from the build completely. > 2. ziptool is built for the target system, but "make" attempts to run it on > the build system to create test data. Autotools did not do this if "make > check" was not run. That was fixed shortly after 1.4.0 already: https://github.com/nih-at/libzip/commit/e9244b207c0fc883ff84c1fc46602feb1e2b0347 > 3. nonrandomopentest is once again being built, and this time failing with > a different error: > > CMakeFiles/nonrandomopentest.dir/objects.a(nonrandomopentest.c.obj): In > function `main': > [...]/libzip-1.4.0/regress/nonrandomopentest.c:45: undefined reference to > `zip_random' > > That makes sense, as zip_random is not declared dllexport. And it shouldn't be exported either in the general case, but it's needed for this test to try out if zip_random is used from the replacement DLL, or if the original one is used. Do you have a suggestion on how to solve this? Or should we just skip this and the non-random AES encrytion tests on Windows? Thomas
Made by MHonArc.