[plt-scheme] create executable: "cannot use _loader file"

From: Anton van Straaten (anton at appsolutions.com)
Date: Tue Oct 12 21:05:57 EDT 2004

I'm getting an error message when creating an executable from DrScheme,
which I've been able to work around, but I'd like to get a better
understanding of what's happening.

The application I'm building consists of a single collection of my own code,
called "baz" below, plus the usual PLT dependencies.  For various reasons, I
chose to build my collection using:

  mzc --collection-extension baz

This part works fine, but if I then use Create Executable from DrScheme, and
select the options to create a Stand-alone MrEd executable (necessary for
this application), I get the following error message:

get-module-code: cannot use _loader file:
"F:\\foo\\src\\bar\\collects\\baz\\compiled\\native\\win32\\i386\\_loader.dl
l"

...and the executable doesn't get created.  If I get rid of the compiled
code, I can then create the executable just fine.  After creating the
executable without the compiled code, I can recompile the collection as
above, and prove that the compilation has taken effect by deleting the
source files.  The executable works perfectly either way (I've tested it on
a machine without DrScheme or my source).

So, the above error is a minor inconvenience at best, but I wanted to check
whether I'm doing something wrong to cause it.

In case it's of any significance, I have an info.ss file in this collection
which looks like this:

(module info (lib "infotab.ss" "setup")
  (define name "Product Name")
  (define foo-libraries (list "main.scm other.scm"))
  (define foo-launcher (list "Product Name")))

I have no idea whether this is doing what it's supposed to do, I'm just
using cargo cult practices when it comes to some of this stuff (copy &
fiddle in what I hope are vaguely appropriate ways).  When I build the
executable, I have the file "main.scm" (not its real name) opened in
DrScheme.  I wondered if this caused DrScheme to open the _loader.dll for
that collection, thus perhaps preventing it from being used during
executable generation.  If that's the case (or even if not), is there a
better way to do this?

Thanks for any insight,

Anton



Posted on the users mailing list.