I have a question to the list, if anyone here knows details of how windows dlls work.
I cross compile for windows with
./configure --host=x86_64-w64-mingw32 --enable-mini-gmp CXX=/bin/false make
and run tests with
make check EMULATOR=wine64
It fails the ecc-dup and ecc-add tests, in this and similar asserts:
ASSERT (ecc->dup == ecc_dup_jj);
Here, the right hand side is a symbol from libhogweed-x.dll, and on the left hand side, ecc refers to a constant struct in the same dll.
My guess us that dynamic linking on windows doesn't provide function pointer comparisons as specified by the C standard. Maybe left-hand side is the real function entry point, and the right hand side is the address of some glue code related to dynamic linking. Is that right? If so, I can just disable this assert for windows, but I'd like to understand what'g going on.
I think the reason it works with ELF, is that ELF dynamic linking tries harder to make all references point to the same PLT glue code, but I don't fully understand the details there either.
Somewhat related to this: The ecc pointer is taken from this array in testutils.c:
const struct ecc_curve * const ecc_curves[] = { &_nettle_secp_192r1, &_nettle_secp_224r1, &_nettle_secp_256r1, &_nettle_secp_384r1, &_nettle_secp_521r1, &_nettle_curve25519, &_nettle_curve448, &_nettle_gost_gc256b, &_nettle_gost_gc512a, NULL };
The entries are references to data objects in the dll. I'm a bit surprised that works at all, is it expected to work? I had the impression that dlls only exported functions. Should the test code be changed to use the advertised getter functions, nettle_get_secp_256r1 and friends?
Regards, /Niels