I compiled (on Windows 10, using MinGW) a Dynamic Link Library that implements an interface to another one. I then use LibraryLoad[dependencyDLL] and then LibraryFunctionLoad[interfaceDLL,...] to expose a function to the Mathematica Kernel. When I try to use that function the Kernel crashes. That makes me suspect that the Wolfram Kernel cannot find the dependency DLL (which is not in my %PATH%).

I have no doubt that my interface is correct as everything above worked as intended on a Linux machine. I can confirm that my Windows compilation is correct as the test program (written in C) ran correctly.

How can I test if the Wolfram Kernel can see and load the dependencyDLL?


FindLibrary[dependencyDLL] outputs a path to the DLL. So Wolfram can see the library (if not, that would output a $Failed). Maybe its the interfaceDLL that cannot see its dependency?

Edit: further info

I could make it work on a Mac. Putting the dependency DLL on my PATH did not solve the problem (on Windows). I suspect it is something related to linking and other dependencies that I am unaware of (my dependecy DLL is provided by third parties).

I tried to build a minimal working example where I would reproduce that behavior. I could not...

The question remains: how can I see if the Kernel is crashing with a message of undefined reference or similar?

Edit: further info 2

The third party DLLs I am trying to use are intel's MKL. It seems that Mathematica has its own internal version of the MKL, thats why it did not crash on Linux and MacOS; but somehow the windows version is failing.

As per a comment: Using the Visual Studio compiler would be too much trouble as it does not comply to the C99 Standard, in which my code is based a lot (specially complex.h). I have no guarantee that these DLL are compatible with MinGW (gcc on Windows), but all pure C programs I've run so far on Windows did it without crashes. That's why I suspect it is a Mathematica side problem.

  • 1
    $\begingroup$ I would expect LibraryLoad and/or LibraryFunctionLoad to fail if there actually was a dependency problem $\endgroup$ – ilian Jan 3 at 2:47
  • $\begingroup$ "I have no doubt that my interface is correct as everything above worked as intended on a Linux machine." That it appeared to work on Linux is actually no guarantee at all that you have no bug. $\endgroup$ – Szabolcs Jan 3 at 8:57
  • $\begingroup$ Dependencies must be explicitly loaded with LibraryLoad. If you have a mylib.dll that uses the LibraryLink API, and depends on otherlib.dll, then you would first LibraryLoad["othrelib.dll"], then use LibraryFunctionLoad (not LibraryLoad!) to load the functions from mylib.dll. $\endgroup$ – Szabolcs Jan 3 at 8:58
  • $\begingroup$ I do LibraryLoad[dependency] before LibraryFunctionLoad[mylib]. I've put further info... $\endgroup$ – Pedro H. N. Vieira Jan 4 at 19:00
  • $\begingroup$ On Unix-like systems, it helps to run the kernel in command line mode. It will often output something to the terminal when it crashes. I do not know if this helps on Windows. If you try, try math.exe, not MathKernel.exe. However, as Ilian said, a missing dependency should not cause a crash, and does not usually cause a crash. Loading errors can be checked with LibraryLink`$LibraryError (but if the kernel crashes you obviously can't do that). To verify the dependencies of a DLL on Windows, use DependencyWalker. $\endgroup$ – Szabolcs Jan 4 at 22:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.