On windows XP-SP3 and 7, I used "Visual Studio 2008 Express Edition" to compile C-code as a loadable Tcl extension (complete with the requisite _Init entry point for Tcl). It was linked against 8.6 stubs. Seemed to work fine. Then changed the Visual Studio project to incorporate the pre-built-for-windows FFTW package DLL. This required running the VS "lib" utility against a supplied ".def" file to produce a ".lib" file to incorporate into the project, thereby allowing an "automatic" system 'load' of the FFTW package dll at the time the Tcl extension DLL was loaded by the Tcl "load" command.
This too went well. Everything seemed to work, and a tested beta version using a wrapped Tclkit executable ("starpack"?) was shipped to the customer. The version shipped to the customer used tcl86b1.exe (Pat Thoyt's build of Tclkit for windows). The "load" command executed as part of the "package require" for the binary extension failed with "<dll filename> invalid argument" at the customer's site. This problem persisted on multiple machines, using XP and 7 as the OS, and regardless of whether the 'load' was executed by tcl858.exe or tcl86b1.exe.
By momentarily changing the name of the FFTW DLL on a problem machine, the problem still manifested itself in the same way suggesting that the Tcl+OS load mechanism was choking before any attempt was made to 'lookup' the FFTW DLL that was to be automatically loaded, because otherwise we'd expect a "DLL file not found" message.
On a hunch, I suggested to the customer that Visual Studio be installed on one of the problem machines and a retry of the test. Customer replied "..works fine after installing the C# and C++ from a Visual Studio iso file that I burned." No word as to version, but...there ya go.
arjen - 2010-03-10 10:22:37
This sounds more like the FFTW.DLL requiring another DLL that is not shipped (or not copied out of the starkit). We are having trouble with some compiler run-time libraries where systems may hold different versions and the wrong one gets loaded. That sort of situation might explain the phenomena too.
jdc - 2010-03-10 10:46:35
Looks like missing Visual C runtime DLL's. You might need to ship the Microsoft Visual C++ 2008 Redistributable Package . It is very common for computers not to have those DLL's.