OpenSCAD crashes before startup on certain windows machines. Just the newer versions, the 2014 version is fine. So what is going on?
It is hard to debug something on a machine you don't have access to. You can't run it, you can't run a debugger, you can't tweak things, you can't do anything except be polite and hope the bug reporter is patient.
Here is the github issue so far (most of the report is on the mailing list).
My strategy was my usual nonsense... ask the user to try basic stuff like run from the commandline with '--info'.
Then feel through it on instinct and then start applying logic. If something crashes before main() with no feedback from the program at all, something is probably messed up in the basic fundamental build process. For example if you have .h header files from version 2 and .lib/.dll/.a/.so library files from version 2.14.4 of some random library, then the linker might get really confused and the CPU would start calling bizarre places in memory that are full of junky weirdness. So. Maybe it is something in the basic build process that is a problem.
Fortunately thanks to a lot of people doing a lot of hard work there are multiple build systems for OpenSCAD for Windows. One is a static cross-compile using the MXE cross compilation system, from linux to Windows (TM). Then there is MSYS2 which runs on windows itself using cygwin / mingw style tricks.
So I have tried uploading a new build of OpenSCAD using MSYS2 .... after quite a few patches to the packaging system in release-common.sh. And dealing with the fact that the MSYS2 build doesn't currently use a "static" build (with the libraries included directly into the .exe program instead of being linked at runtime from separate .dll files). And also dealing with the fact that Qt5 is very different from QT4.... it didn't work. .. . . it requires a completely different "deployment" process for a program written with QT5 to work on a different machine.
So after a lot more work i finally figured out how to ship a QT5 program with .DLL library files.
I hope the user is not too frustrated by now... maybe we can figure out what is wrong.
After all... we have done it before... this kind of 'remote debugging', back a few years ago when QT OpenGL did not work at all properly on Windows. MichaelAtOz I believe tested that one until it got fixed finally.
This kind of thing makes me smile when I listen to the NASA folks talk about giving commands to a robot on Mars, and having to wait 40 minutes for an answer. I have to wait an hour or two for a single clean build (on a Windows VM on my machine) and sometimes a few days for a debug report from the patient user. And I have no specs on the machine the User has.... only their descriptions! Course the stakes are much much lower.