Opened 10 years ago
Closed 8 years ago
#1225 closed enhancement (fixed)
Strange static compilation behaviour
| Reported by: | Kooda | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | someday |
| Component: | compiler | Version: | 4.10.x |
| Keywords: | Cc: | ||
| Estimated difficulty: | medium |
Description
I’ve been experimenting on static compilation of CHICKEN programs in the last few days and stumbled upon this weird behaviour.
Here are the files used:
;; mod.scm
(module mod
(func)
(import scheme chicken)
(define (func) (print "Hello world!")))
;; test.scm (use mod) (func)
When compiling the module with -J, everything goes well:
$ csc mod.scm -c -J -unit mod $ csc test.scm mod.o -uses mod -static-libs $ ./test -:D [debug] application startup... [debug] heap resized to 1048576 bytes [debug] stack bottom is 0x7fff266950b0. [debug] entering toplevel toplevel... [debug] entering toplevel library_toplevel... [debug] entering toplevel build_2dversion_toplevel... [debug] entering toplevel eval_toplevel... [debug] entering toplevel expand_toplevel... [debug] entering toplevel modules_toplevel... [debug] resizing mutation-stack from 8k to 16k ... [debug] entering toplevel chicken_2dsyntax_toplevel... [debug] entering toplevel mod_toplevel... Hello world! [debug] forcing finalizers... [debug] application terminated normally
Now if I remove mod.o (note that I keep mod.import.scm so the compiler knows about the module) and recompile the application, here is what happens:
$ rm mod.o $ csc mod.scm -c -unit mod $ csc test.scm mod.o -uses mod -static-libs $ ./test -:D [debug] application startup... [debug] heap resized to 1048576 bytes [debug] stack bottom is 0x7ffea745e110. [debug] entering toplevel toplevel... [debug] entering toplevel library_toplevel... [debug] entering toplevel build_2dversion_toplevel... [debug] entering toplevel eval_toplevel... [debug] entering toplevel expand_toplevel... [debug] entering toplevel modules_toplevel... [debug] resizing mutation-stack from 8k to 16k ... [debug] entering toplevel chicken_2dsyntax_toplevel... [debug] entering toplevel mod_toplevel... Error: (import) during expansion of (import ...) - cannot import from undefined module: chicken Call history: mod.scm:1: eval <syntax> (import scheme chicken) <--
Change History (7)
comment:1 Changed 10 years ago by
| Milestone: | someday → 4.11.0 |
|---|
comment:3 Changed 10 years ago by
Using -no-module-registration is the right thing in this situation.
The reason for the observed behaviour is as follows: when compiling a file with a module in it, the module information has to go somewhere by default. When -emit-import-library (or -J) is used, that information is put in the generated import file. If the module information isn't emitted, however, it's left within the compiled file itself so that the semantics of the program are preserved.
Obviously in the example above that's not desirable, since it leaves import forms within the compiled code. -no-module-registration is the right way to disable this behaviour.
comment:4 Changed 10 years ago by
| Type: | defect → enhancement |
|---|
As this is a gotcha rather than a bug, and it isn't immediately clear what CHICKEN should do instead, I'm leaving this open but changing it into an enhancement.
comment:6 Changed 9 years ago by
| Estimated difficulty: | → medium |
|---|
comment:7 Changed 8 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I was going to close the ticket as wontfix because it just seems to be a bad way of using the compiler options, but it seems to be working with CHICKEN 5!

A workaround seems to be to add
-no-module-registrationon the compiler command line which ties everything together.