Jeremy Drake <g...@jdrake.com> writes: On msys2's MINGW-packages, we recently hit an issue[1] which I eventually tracked down to the very issue documented in https://gmplib.org/repo/gmp-6.2/file/09e101b6f2ff/acinclude.m4#l2128
This is a link to a huge file. Many things are mentioned there. > > My current theory is that for some unknown reason, gmp's assembly > > functions are resulting in symbols that bfd believes are data, not > > functions. Without dllimport, this is causing it to use the > > auto-import hack, which has the Windows loader modify addresses in the > > function itself, rather than using the jmp thunk which references the > > `__imp_` symbol. This cannot work correctly on x64 with large > > addresses, because the CALL instruction is taking a 32-bit relative > > operand. The only way this can work is with a jmp thunk (unless the > > compiler knew to generate an indirect CALL, which is what dllimport > > does). > > The 'unknown reason' I mentioned is that the functions were lacking > `.type 32`. > > > gmp's configure script checks for support for .type pseudo-op, but on > > mingw that is only allowed inside a .def, and must take an integer not > > `@function`, so gmp suppresses it altogether. Strangely, the fix for this was only applied to x86, and not x86_64. This patch applies the fix to x86_64. What *fix* are you talking about? You need to give us some context. Please allow yourself a little time to word your message to give us a chance to follow you. I recently tried to install msys2 on a Windos 10 system here. I had some problems and tried to contact the msys2 people at their mailing list. The message was silently dropped. Thus, I gave up on msys2 and returned to cygwin. That's our path forward now. -- Torbjörn Please encrypt, key id 0xC8601622 _______________________________________________ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs