chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Chicken-users] RE: Win32/cygwin dynamic loading


From: Jonah Beckford
Subject: RE: [Chicken-users] RE: Win32/cygwin dynamic loading
Date: Mon, 24 Feb 2003 19:37:48 -0500

Sounds good.  Completely agree on not using C_shlib; it's ugly and
shouldn't be used as anything more than a virtualized reference
implementation.  Hope you also ignored the "canonicalized" build stuff;
it's a little side project of mine.  The blurb about cygwin (and mingw)
has a simple answer: the current version of libtool (which uses dlltool
et al.) only needs to have a dllimport on variables, and that's it.  My
first runthrough did that and it works great.

On reflection about the one-to-one mapping, yeah, libsrfi and libstuffed
(and whatever libraries in the future) should stay for static linking
(or .so linking on .so platforms).  My reason for thinking it was
necessary now eludes me, probably because that restriction isn't needed
if you go back to explicit (load "main-unit-module") and (load-library
"nonmain-unit-module" "...") instead of the implicit (declare (uses
xxx)).  However, to my untrained eye that looks like changing the .scm
source code whenever we switch from dynamic loading to static linking.
Is there a way around this?

The thread-safety is a side issue and can wait, but it seems like it
will raise its head in the future ... it is always easier to plan for it
and then implement it in the future, rather than try to make code thread
safe when the project gets too large.  Luckily, there are a lot of
approaches to this, and maybe it will be possible to extend the current
Chicken threading code without touching the other code ...

Also seems I need to look into the eggs a little closer :)

Looks like we have covered all the bases.

Jonah

-----Original Message-----
From: felix [mailto:address@hidden 
Sent: February 24, 2003 5:49 PM
To: Jonah Beckford
Cc: 'Felix Winkelmann'; address@hidden
Subject: Re: [Chicken-users] RE: Win32/cygwin dynamic loading


Jonah Beckford wrote:
> 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).

> - Runtime, as opposed to link-time, resolution of units (using
> load/load-library)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]