Java binding issue with MinGW GCC on Windows about blst HOT 11 CLOSED

See if following helps

--- a/bindings/blst.swg
+++ b/bindings/blst.swg
@@ -478,6 +478,9 @@ extern const blst::P2_Affine BLS12_381_NEG_G2;
 %begin %{
 #ifdef __cplusplus
 # include "blst.hpp"
+# ifdef __MINGW32__
+#  undef __int64
+# endif
 using namespace blst;
 #else
 # include "blst.h"

from blst.

On related note, I'd argue that MinGW might be suboptimal choice in the context. Because MinGW C++[!] leaves references to mingw-specific .dlls. So that if you move .dll to another system, you'd have to drag along those extra .dlls. Again, this is C++-specific problem, in sense that C is OK. It might be possible to resolve C++ by using more -static-this-or-that options... Could you see if you can come up with something? Otherwise Visual C would be more suitable...

from blst.

See if following helps

Just in case, "helps" means that the JNI module works with your application. I mean I can confirm that I can compile blst_wrap.cpp with x86_64-w64-mingw32-g++ on Linux, but question is if the whole thing works.

from blst.

See if following helps

Yeah, thanks 👍 That helped on Win as well. Java printed "OK"
Will check on a clean Windows a bit later, however I've checked with depends.exe and the resulting DLL depends only on

• kernel32.dll
• msvcrt.dll

The latter should be a part of OS starting from win 10. Earlier Wins would need to additionally install MSVC redistributables (if I'm not missing anything)

from blst.

Are you OK with integrating this patch on your side?

from blst.

kernel32.dll and msvcrt.dll are 100% "green." It's just that on my virtual computer I had extra .dll, mingw-specific ones. Hmm... What are your versions? I mean compilers...

As for integrating, yes, but I'll think about it a bit longer. I mean it will be integrated in some form, not necessarily in exactly suggested one...

from blst.

What are your versions? I mean compilers...

$ gcc -v
Using built-in specs.
COLLECT_GCC=E:\TDM-GCC-64\bin\gcc.exe
COLLECT_LTO_WRAPPER=E:/TDM-GCC-64/bin/../libexec/gcc/x86_64-w64-mingw32/9.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-git-9.2.0/configure --build=x86_64-w64-mingw32 --enable-targets=all --enable-languages=ada,c,c++,fortran,lto,objc,obj-c
++ --enable-libgomp --enable-lto --enable-graphite --enable-cxx-flags=-DWINPTHREAD_STATIC --disable-build-with-cxx --disable-build-poststage1-with-cxx --
enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libstdcxx-threads --enable-li
bstdcxx-time --with-gnu-ld --disable-werror --disable-nls --disable-win32-registry --enable-large-address-aware --disable-rpath --disable-symvers --prefi
x=/mingw64tdm --with-local-prefix=/mingw64tdm --with-pkgversion=tdm64-1 --with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: posix
gcc version 9.2.0 (tdm64-1)

from blst.

I've double-checked on my virtual machine and I do get additional dependencies on libgcc_s_seh-1.dll and libwinpthread-1.dll. This is gcc-10.2.0 msys2 package, installed with pacman -S mingw-w64-x86_64-gcc. Your TDM thing is clearly different. It ought to boil down to how exception support is implemented. There are different options, but I don't see any specifics chosen in "configured with" lines. It might happen that some default has changed between 9 and 10. Either way, if compiler is configured in a way that resulting .dll refers only to kernel32.dll and msvcrt.dll, then there is no reason to not use it:-) Go TDM!

from blst.

It might happen that some default has changed between 9 and 10.

Oh! Whole idea behind TDM is to not have migw-specific .dlls. It's not about defaults, but about alternative goal. Cool!

from blst.

Whole idea behind TDM is to not have migw-specific .dlls.

Oh nice, so it turns out that TDM-GCC is a separate compiler build atop of MinGW-GCC. Good to know :) Thanks for that info 👍

from blst.

🚀 Thanks for the prompt fix!

from blst.