3

I recently set about to re-compile some old (2008-2009) applications that use MathLink in preparation for creating new, modified versions. Mathlink has been deprecated but WSTP seems like a fairly painless replacement and I had no trouble getting the code to compile and the project to build under Visual Studio 2013.

Unfortunately, the resulting code doesn't run correctly. Whereas the old code, if double-clicked, did this:

enter image description here

the new one does this

enter image description here

The "missing" DLL is definitely on the drive, and the project would not have compiled without it. Putting an extra copy into the application directory doesn't help.

DependencyWalker reports as follows:

enter image description here

Which seems to restate the problem in other words but doesn't bring me to a solution.

The DLL has been included in the project, but Visual Studio marks it "Does Not Participate in Build," which seems as though it might be a problem but it's not at all obvious what to change it to.

enter image description here

Any suggestions?

Michael Stern
  • 4,695
  • 1
  • 21
  • 37
  • 1
    My first intention would be to use the dependency walker on the created executable and see what it shows you about the library that is missing. – halirutan Feb 18 '15 at 19:58
  • Perhaps you'll find some useful info here: http://mathematica.stackexchange.com/a/74132/12 I haven't encountered this particular problem you mention. – Szabolcs Feb 18 '15 at 20:00
  • Also note, "The WSTP dlls are no longer installed in the Windows System32 (SysWOW64) directory. Instead these libraries are contained in the Wolfram System layout." – Szabolcs Feb 18 '15 at 20:01
  • Finally: you can copy these DLLs next to your application, just make sure you know which one (which version) is needed. I believe they can even be distributed for as long as you abide by the license. – Szabolcs Feb 18 '15 at 20:03
  • What DependencyWalker shows is unusual. First, did you use the MathLink development kit or the WSTP one? If it's an old program that uses the ML naming convention then you should use the MathLink one and use DLLs named as ml64i3.dll or ml64i4.dll (for interface version 4). Since it's an old program and you might want to ensure compatibility with v9 too, I suggest using interface version 3. – Szabolcs Feb 18 '15 at 20:15
  • @Szabolcs I took my old code, replaced the MLwhatever calls to WSwhatever, pointed to the WSheaders and WSlibraries, and it compiled and built, but with the confounding outcome above. I'll try changing the interface version and report back. – Michael Stern Feb 18 '15 at 20:21
  • @MichaelStern I've never used the WS-functions, but I believe the only difference is in the naming (plus that WS should be available for interface v4 but maybe not v3??). It's more likely that the problem is with the linking or maybe compilation steps. – Szabolcs Feb 18 '15 at 20:24
  • @Szabolcs specifying interface 3 changed nothing. It's so odd; if the .dll were actually missing, how could the application even build? And if it's not missing, why can't the binary find it at run-time? Perhaps this is a problem from StackOverflow. – Michael Stern Feb 18 '15 at 20:35
  • Sorry, I never seriously used Visual Studio ... I compiled directly from the command line. If you like, later today I can show you my makefiles (for Windows, also with Microsoft's compiler), and you can try compiling from the command line. If that solution works, then you can try figuring out what VS does differently – Szabolcs Feb 18 '15 at 23:05
  • Update: I am able to get the code to run if I have copies of the DLL in the Debug directory. However, after running (whether launched from the desktop or from within Mathematica), it crashes before doing anything useful. – Michael Stern Feb 20 '15 at 20:57

1 Answers1

5

I asked the above question a long time ago and have since successfully written several WSTP programs. I can't say for certain what caused the above problem, but it is likely that I placed the necessary DLL in the source code directory rather than the Debug directory and/or failed to maintain proper path setups for resources in the Visual Studio IDE.

In my current work, I have copied the .lib files into Visual Studio's normal search path, and in the Solution Explorer I include only wstp32i4.lib among the Resource Files. I don't know if including the others causes problems, but it certainly doesn't help.

Also be sure to include wstp.h in the Header Files.

Michael Stern
  • 4,695
  • 1
  • 21
  • 37