Gisle Vanem <gva...@online.no> writes: >> It would also be nice to setup some windows tests in the ci system >> (which runs on a repo mirror at >> https://gitlab.com/gnutls/nettle/-/pipelines), cross-compile + wine would >> be the easiest for me to setup, but I think there are also some windows >> "runners" that could maybe be used to try native windows builds. > > Good. But this means some MinGW build?
For CI, I was thinking of something similar to what I do for manual tests. Build machine runs debian gnu/linux. Then use the mingw crosscompiler to create windows libraries and executables, and let the testsuite use wine to run the various test programs. > Using Microsoft's 'cl' > seems impossible at the moment. E.g. how to make 'configure.ac' > NOT assemble via 'cl'? Now I get: > cl -I. -DHAVE_CONFIG_H -nologo -MD -c umac-nh.s > cl : Command line warning D9024 : unrecognized source file type > 'umac-nh.s', object file assumed > cl : Command line warning D9027 : source file 'umac-nh.s' ignored > cl : Command line warning D9021 : no action performed That's the rules in Makefile.in, which uses the same $(COMPILE) for both .c and .s source files. To use something different (what's the right assembler to use) would need changes to both Makefile.in and configure.ac. And I'm not able to test those things, so would need help from someone with windows experience and who also knows (or is willing to learn) autoconf. > See above. And besides, a generated 'config.make' has > 'NUM_BITS = 0' causing a div-by-zero exception in e.g. > eccdata$(EXEEXT_FOR_BUILD) secp192r1 8 6 $(NUMB_BITS) The autoconf magic to determine that is rather hairy, but as far as I'm aware, it is supposed to only require a compiler that comply with the C standard. Essentially, I think it compiles test code with char foo[sizeof(unsigned long) - x]; for various x (binary searching) and relies on a compile error if the size evaluates to a negative value. In case you want to investigate, you'd have to start with config.log which contains more details on the tests run. > All this autotool stuff is a total obfuscated mess if you ask me. I'm not so fond of the collective "autotools" terminology. Nettle uses autoconf, m4 and GNU make, but not automake or libtool. > But the speed of e.g. 'nettle-benchmark.exe' absolutely sucks > compared to a Cygwin x64 build of the same. Results attached. Odd, and a factor 4 difference also for algorithms in plain C, e.g., md2 and md4 which are somewhat obscure and not particularly optimized. I don't have a good explanation for that. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se
