Opened 9 years ago
Closed 7 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 9 years ago by
Milestone: | someday → 4.11.0 |
---|
comment:3 Changed 9 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 9 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 8 years ago by
Estimated difficulty: | → medium |
---|
comment:7 Changed 7 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-registration
on the compiler command line which compiles mod.o.