Package Steps

[terrancesnyder]

So we've been using ZMQ for awhile now, however, we run into a snag. The latest small issue we have is that we can confirm on our dev PCs that we can compile, build, and run our application.

Now we'd like to package it up and send it out in the field. It is not realistic to require our PCs in the field to install VS 2010, Windows 7 SDKs, Python, etc as we dont want people to compile our client. Nor do we want to distribute over 1.2GB of needless SDKs to dumb PC terminals.

When we compile and run on the same hardware and software version (with the dev tools) and then zip and try to run on the same hardware and software (sans dev tools) anytime we try to "require('zmq')" the program simply exits, no crash, no unhandled exception.

The simpliest thing we did was even a simple "test.js" with

console.log("Trying to load");
var zmq = require('zmq');
console.log("Loaded!");

And this basic script will simply exit, after spitting out "Trying to load".

We've thought this was related to VS 2010 redistributable - so we folded and even installed this on the client PCs, confirming C:\windows\system32 had the msvcrxxx.dlls however to no effect on the end result of node simply refusing to include the ZMQ libs.

Any hints on how to resolve this or what the core libs are required to run on a win32 that we should include.

If we find out anything we'll be sure to update this side as well.

[kkoopa]

Unfortunately Windows isn't the best OS for doing any development but .Net... Anyway, this sounds like the binding has problems loading libzmq. At the end of binding.cc is the Windows-only delayload part where it tries to load libzmq. Run that through a debugger or insert fprintf(stderr, ...) calls to see that it is successful in loading everything. It looks for the libs in specific locations, so you would have to change the lookup paths if you don't have the same directory structure as this repo.

On October 22, 2015 4:43:02 AM GMT+03:00, terrancesnyder notifications@github.com wrote:

So we've been using ZMQ for awhile now, however, we run into a snag. The latest small issue we have is that we can confirm on our dev PCs that we can compile, build, and run our application.

Now we'd like to package it up and send it out in the field. It is not realistic to require our PCs in the field to install VS 2010, Windows 7 SDKs, Python, etc as we dont want people to compile our client. Nor do we want to distribute over 1.2GB of needless SDKs to dump PC terminals.

When we compile and run on the same hardware and software version (with the dev tools) and then zip and try to run on the same hardware and software (sans dev tools) anytime we try to "require('zmq')" the program simply exits, no crash, no unhandled exception.

The simpliest thing we did was even a simple "test.js" with

console.log("Trying to load");
var zmq = require('zmq');
console.log("Loaded!");

And this basic script will simply exit, after spitting out "Trying to load".

We've thought this was related to VS 2010 redistributable - so we folded and even installed this on the client PCs, confirming C:\windows\system32 had the msvcrxxx.dlls however to no effect on the end result of node simply refusing to include the ZMQ libs.

Any hints on how to resolve this or what the core libs are required to run on a win32 that we should include.

If we find out anything we'll be sure to update this side as well.

---

Reply to this email directly or view it on GitHub: https://github.com/JustinTulloss/zeromq.node/issues/461

[reqshark]

@kkoopa, if my memory serves us... I encountered an impasse of constraints after compiling x86 and x64 targets on modern windows.. and that was after getting the visual studio linker to build ZeroMQ4 with libsodium... At that point, you were able to somehow program around those dll loading problems I had

So if those dlls back from #431 are still in play, then it's worth noting that I used VS 2013 to do the aforementioned libsodium linker magic against ZeroMQ 4

so.. I would recommend: • either update your VS 2010 stuff • or use an older version of the node zmq module in that type of windows situation

[terrancesnyder]

Thanks all, we've run a dependency walker on the libzmq as well as the node bindings generated content. Looks like we were missing some DLLs. Again, once we find this out we'll throughly document how we got things working. We'll also try @kkoopa suggestion around bindings.cc if it still doesn't work

[terrancesnyder]

Ok problem solved.

The issue was a couple things.

We use ZMQ V9 (old XP boxes running in the field) which is VS2008. We use node ZMQ which uses node-gyp which uses VS2010

The issue was node ZMQ needed VS2010 C++ redistro The issue after that was the PCs also needed ZMQ VS2008 C++ redistro

After those two dependencies were installed everything ran fine.

We'll be looking at how to take the redistro's and package them with the application rather than forcing an MSI install. From what guidance we see on M$ website, you "should" be able to take all the required VS20\ DLLS and libs and put them beside node.exe (standalone) and the DLLs wont need to be put into system32 (requiring admin perms).

[kkoopa]

Good that you got it resolved.

It at least used to be that local dlls always got picked up over system dlls, but that partly changed in the nearly fifteen years since the release of Windows XP, as it became regarded as a security concern. Don't actually know how everything is set up nowadays, if it only applies to some libraries, and so on.

As you probably know, you can run MSI installers silently in the background. It is also possible to extract their contents by performing a network install to a specified folder with the /a flag. If the dlls do not require registering with regsrv32, it might thus be possible to just get the installer to dump the dlls in a good location.

[terrancesnyder]

@kkoopa thanks, likely going to do your trick for the /a flag. this is old code as out in the field there are many old windows XP boxes and sometimes embedded windows so were on a fringe side of things, hopefully what we learn here can be added for posterity. thanks so much for your help.