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

[felix]

Jonah Beckford wrote:
> Yes, cygwin/mingw32 libtool handles most things, except 
> 1. dllimports of DLL data (ie. extern'd variables).  Needs an explicit
> __declspec(dllimport) attribute on the 'extern'.
> 2. It also doesn't allow backlinking (there are other operating systems
> that don't allow this as well).  That means you cannot have a DLL have
> an external reference to some function or data in the main application;
> one area it comes up in is that C_toplevel (defined in the application)
> is always needed by a CHICKEN module/DLL.
> 3. Some platforms (ex. AIX, and Win32 to some extent) require a
> self-contained shared library.  That means that srfi-37 in a shared
> libsrfi cannot depend on regex in a shared libstuffed, and lolevel in a
> shared libstuffed cannot depend on srfi-4 in a shared libsrfi.  (note:
> those are the only non-self-contained examples in the current CHICKEN).
> Actually, Win32 will allow a non-self-contained shared library, but
> cygwin/mingw libtool cannot be easily made to accept the circular
> dependency of libsrfi <-> libstuffed.
>
> What I did ...
>
> Good and easy solution for 1:  Just put __declspec(dllimport) on the
> variables in chicken.h if BUILD_CHICKEN_DLL was not defined.

No problem, here.

> Not-so-good solution for 2: Require an extra parameter to
> CHICKEN_initialize/invoke/run that is a pointer to the C_toplevel.  Then
> this pointer to C_toplevel can be passed to the unit when it is loaded
> from the DLL.  Not-so-good because it is an backwards-incompatible
> CHICKEN API change.

Hm. That's tricky. The call to CHICKEN_initialize/run/invoke() is actually
*not* done in the main module, but in libchicken. This means (if I understand
you correctly) that we have to put a main() into the compiled (main) module
that does the initialization, which complicates the creation of dynamically
loadable modules a little (the compiler has to emit different code for
library units, main units and dynamically loadable main units. The latter
may not contain a main(), of course). But we can fix this, too.

Don't worry about backwards compatibility. Full support for dynamic loading
is far more important.

> Horrible solution for 3: Just move regex.o and srfi-4.o into libchicken.

I just threw out the serialization stuff from lolevel (it was crappy -
I have to do a better, port-based implementation at some stage), so that
unit is ok. For srfi-37 we will have to do the option parsing by hand.

> So I got it working on cygwin and mingw32 (just for proof-of-concept)
> but the method can be improved substantially to not rely on libtool
> (Visual C++ should still be a viable compiler to produce DLLs, as a
> Visual C++ application with a mingw DLL cannot be debugged easily) and
> to make the dynamic loading be available on all platforms that support
> any kind of shared library (even if it is quite primitive).  

One more point is that we need a Win32 version of C_dload().
I can add the LoadLibrary()/GetProcAddress() stuff, but does
dlopen() and friends work with cygwin?

> I will present the solution after I have the new proof-of-concept
> working ...

Very good. I'm looking forward to that.


cheers,
felix