[Top][All Lists]
[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, 17 Feb 2003 23:45:13 -0500 |
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