Oh yeah, just forget to make something explicit ... this dynamic loading
was just a proof of concept. The goal was to find a set of principles
to support dynamic loading on the broadest of platforms (basically, code
normalization). Now that I think we have most of the principles
(outlined below), I would still use __declspec(dllimport) for Win32
(which should work if the "principles" are followed) etc. and only use
the "primitive" shared loading technique for trully primitive platforms
and maybe for thread safety.

Agreed. I appreciate the work you've put into this, and I'm sure
we will be able to add at least part of your changes into the core
system. But I have to add a few comments, since, to be frank, I'm not
completely happy with it:
- The performance impact we have with the C_shlib device is pretty hard.
In fact a little bit to heavy for me. Thread-safety is definitely an
issue, but I'm not eager to reduce overall performance more than
absolutely necessary. If I understand the machinery you devised correctly,
this is not needed on platforms that have some form of dynamic loading.
Specifically: win32, cygwin, mingw32. That's fine with me. But supporting
anything more than windows and most unices is, strictly speaking,
not worth the effort.

- A one-to-one mapping between units and shared libraries

Hm. I understand, but I like to keep the number of libraries small.
(at least for the base system).

Ok. Yet, (again): the base system should work in a static-linking
environment, too.

- The call to (load "xxx") for a dynamic module must not use any prefix
or suffix (like prefix=lib, suffix=.so). In fact, it will be difficult
to support any paths like (load "/usr/local/chicken/srfi-13") ... not
only is that system-dependent, the parsing routine used to search for
alternatives like /usr/local/chicken/cygsrfi-13-0.dll would be quite
difficult. The dynamic modules must be locatable with a standard
mechanism (maybe search the current directory, followed by the
system-dependant library search path, followed by CHICKEN_HOME). This
also means they must be installable with a standard mechanism (I like
William Annis' suggestion of something like Python's Distutils or Perl's
Makefile.PL; I haven't looked at "eggs" yet, but I have a suspicion they
are for pure Scheme code).

The extension-mechanism (the "eggs") is actually intended exactly for this
problem: having a standard way of loading compiled code dynamically.
That `load' uses proper pathnames is Ok, IMHO. `require' (and
`require-for-syntax') uses the pathnames found in the extension
registry and (if not found there) in the current path and the include path.
It's really just a wrapper for `load', which constructs some standard
pathnames and searches for something suitable for loading.

- Specification of -static or -shared when using chicken-config (so it
can pick the right libruntime) and change the compiler -D defines. This
also means the chicken-config, or its replacement, must be useable on
all platforms.

On windows we can also use `csc.bat'.
I propose a somewhat different approach. It probably has it's own set of
problems, but bear with me:
1) The compiler emits a `C_main_entry_point' for non-units (or main-units,
i.e. code that doesn't have a `unit' declaration).
2) C_main_entry_point expands into a `main()' (or `WinMain()' if C_WINDOWS_GUI
is defined) that calls `CHICKEN_main()' with the command-line arguments and
`C_toplevel'. If this file is compiled with -DC_SHARED or -DC_EMBEDDED,
C_main_entry_point
is empty.
3) CHICKEN_main() does CHICKEN_initialize() and passes the toplevel pointer.
This will handle the circular dependency from the main code to runtime.c
and back to C_toplevel (since C_toplevel is passed directly).
As a side effect we get rid of libembedded-chicken.
4) So we have the following possible configurations:
- normal main unit (has C_main_entry_point -> main/WinMain)
- dynamically loadable main unit (has C_toplevel and nothing else)
- library unit (linked statically/dynamically/implicit/explicit)
(has no special handling - just the `C_..._toplevel()' as usual)
5) Add the declspec cruft for Win32, with the usual macro hackery for
switching between dllimport/dllexport (I still don't know how cygwin
handles this - can someone explain this to me? Wasn't there something
like dlltool?). Since we have no circular dependencies anymore,
this should work (or not?)
6) Change `chicken-config' and `csc[.bat]' to handle all the options.
It doesn't address all issues yet, but it's a careful start at getting
into the (IMHO) right direction.
What do you think?
cheers,
felix