[Chicken-hackers] [PATCH] Enable using import in static binaries

[felix . winkelmann]

Attached is a patch that attempts to solve the problem of importing modules
in evaluated code when loading of external import libs is undesirable or
impossible (e.g. when using static binaries). I apologize for the size of
the patch, but several interrelated changes need to take place and therefore
require modifications in all sorts of places.

What this mostly does is to provide a core library unit ("eval-modules") that
is available in the static libchicken (and there only) that holds the code for
all core modules import libraries. When compiling a static standalone 
executable,
this unit is executed when starting up and overrides a new hook
("##sys#import-library-hook") that is used to locate import libraries
and which will execute the locally stored module registrations instead
of attempting to load the import library.

I first tried to simple run the module registrations for all core modules
directly in the library unit, but this turned out to be too slow (about 1
second - this is way too slow and needs to be investigated at some stage.)
A side effect of these attempts is a slightly faster implementation of
"merge-se" in modules.scm.

Furhermore, module registration code for standalone executables is now
enabled by default (unless "-no-module-registration" is given, or the new
csc alias "-N"). So modules defined in an executable are available at runtime
when imported by evaluated code. Extracting import libraries with "-j" or
"-J" still drops the module registration, since this makes more sense.

In static extensions, the module registration code is now retained as well,
so linking in static extensions also makes their modules available at runtime.

This patch also incorporates a fix to ticket #1437, by Peter, which lazily 
initializes
the evaluation environment correctly to avoid ordering problems between
imported default modules and modules imported by the user. Note that
this problem still seems to be in effect in statically linked code, possibly
again an ordering issue that still crops up since in that case 
import/registration
code runs at program startup.

This patch made our old friend "test-finalizers.scm" barf again, but
this is totally unrelated (or better, not directly related), since any
changes in the normal startup code will change the allocation pattern
and when GC occurs. This means this particular finalizer case (finalizer
on code literal in interpreted code) is still broken, but should not be the
reason to block perfeclty fine patches, so I have taken the freedom
to disable this test in the master for now (already pushed.)

Finally, tests for the runtime import in compiled code have been added.


felix

0001-Allow-import-in-evaluated-code-in-static-executables.patch
Description: Text Data