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

[Jonah Beckford]

I took your comment about solution #2 into mind ... I don't need to pass
in the toplevel pointer.  I did need to split up libchicken into two
libraries though (a static library that has defns that must be
statically linked [CHICKEN_initialize/run/invoke, main/WinMain/DLLMain
and global data], and a runtime library for everything else).

Also, my 'better' solution to #3 is basically to resolve the
C_<unit>_toplevel at runtime instead of link time.  Circular
dependencies should be fine using the new method; no need to touch the
srfi-37 unit :)

Also, I was using a Win32 dload_2 stub that called
LoadLibrary/GetProcAddress.  This works on all Win32 platforms ...
Cygwin does have a dlopen/dlsym, but it is just a tiny wrapper around
LoadLibrary.

It's mostly finished ... I will tar.gz it up and make it available for
testing in a day or two.

Jonah


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


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