[plt-scheme] Windows Native exe

At Sat, 10 Mar 2007 20:36:00 +0100, a_fasano at hotmail.com wrote:
> Unfotunately when I copy the exe in the c:\mz-360\lib directory, I get:
> 
> "Cannot load libmzgcxxxxxxx.dll" error.

I agree with Chongkai that using DrScheme's "Create Executable" or "mzc
--exe" is a better way to go for most purposes.

But you seem to know what you're doing, so maybe it doesn't work in
your case, or maybe you're dealing with some an older code. Here's
information on you current approach:


When you copied the executable to the "lib" directory, the problem is
that the executable is looking for "libmzgcxxxxxxx.dll" in a further
"lib" subdirectory of the executable's directory. The is error from
MzScheme (via "main.obj"), as opposed to Windows. [Why does MzScheme
look for the DLL? More at the end...]

If you try moving the binary up one level, then Windows won't even
start the executable, because "ciao.exe" needs "libmzgcxxxxxxx.dll",
which isn't in your path. That is, the error will be from Windows, not
MzScheme.

If you add the "lib" directory to your path and keep the executable one
level up, then both MzScheme and Windows will be happy, but that's an
awkward solution.

Since you're presumably recompiling "main.obj" to #define
STANDALONE_WITH_EMBEDDED_EXTENSION, also change the definition of
DLL_RELATIVE_PATH in "cmdline.inc" to L"<". That way, MzScheme won't
look for "libmzgcxxxxxxx.dll", and it's just a matter of having the
DLLs accessible in the usual Windows way. In other words, you get back
to pre-360 behavior.


The reason "mzscheme.exe" works is that it's linked with
"/DELAYLOAD:libmzschxxxxxxx.dll /DELAYLOAD:libmzgcxxxxxxx.dll". And
that's why MzScheme looks for the DLLs: to load them explicitly before
any of the exported functions are used. But the output of mzc is not
compatible with delay-loading (because it directly references
scheme_false, for example). We could fix that, if it matters to anyone.

Matthew