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
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.