From mboxrd@z Thu Jan  1 00:00:00 1970
From: Fergus Henderson <fjh@cs.mu.OZ.AU>
To: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk>
Cc: gnu-win32@cygnus.com
Subject: Re: mingw32: .exe -> .a import libs for DLLs?
Date: Mon, 19 Jan 1998 15:26:00 -0000
Message-id: <19980120101010.09761@mundook.cs.mu.OZ.AU>
References: <x2ra66c3g4.fsf@blueberry.kubism.ku.dk>
X-SW-Source: 1998-01/msg00436.html

On 17-Jan-1998, Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> wrote:
> Arrrgh. I've been messing around with dlltool and friends all day,
> trying to get a DLL to modify a global variable with mingw32, or
> rather Werner Koch's cross-development version of it. Basically, I
> want to (various bits removed for brevity, so this won't actually run;
> dl-routines lifted from Luke Tierney's web page at 
> http://www.stat.umn.edu/~luke/xls/projects/dlbasics/dlbasics.html ):
> 
> -----------
> dltest.c:
> 
> int zip = 0;
> void baz(void);
> 
> main(int argc, char *argv[])
> {
>   void  *libb;
>   void (*foo)(void), (*bar)(void);
> 
>   libb = dlopen("b.dll", RTLD_NOW);
>   bar = dlsym(libb, barsym);
>   printf("zip is @%x\n",&zip);
>   printf("baz is @%x\n",&baz);
> 
>   bar();
>   dlclose(libb);
> }
> 
> void baz()
> {
>   printf("baz called; zip = %d\n", zip);
> }
> ---------
> b.c:
> 
> void bar()
> {
>   printf("incrementing zip @%x\n", &zip);
>   zip++;
>   printf("calling baz @%x\n", &baz);
>   baz();
>   printf("done with bar\n");
> }
> ------------
> 
> OK, so I follow the instruction to make b.dll (relocatable, a.m. John
> Cerney) and dltest.exe. To access baz and zip, I tried to use the
> usual procedure for creating export and import libs for dltest and
> linking them into dltest.exe and b.dll, respectively. This works, as
> far as loading b.dll and invoking it, but the addresses of zip and baz
> are not the same in the two modules, so the zip++ naturally generates
> a GPF. Obviously, they aren't getting properly relocated.

Does it work if you comment out the `zip++'?
I think the procedure that you have described should in theory
work for functions.  That is, in theory functions (but not global
variables) should get properly relocated.

For global variables, the import library will contain a
*pointer* to the global variable, i.e. for `zip', the
import library will contain a pointer `__imp_zip', and
in the module that uses it (b.c), you need to have

	#define zip (*__imp_zip)

The import library will also contain a definition of `zip',
but this will be entirely bogus -- it is a *function*.
(dlltool creates forwarding functions for every exported symbol,
without regard to whether the symbol is a function or not.)
That's why you were able to link "successfully", but zip++
gave a GPF.

> There are some notes on Fergus's page on building DLL's with gnuwin32,
> but quite honestly, I cannot make heads or tails of them...

The notes on my page don't cover the case of linking a DLL in dynamically
using dlopen() or its Win32 equivalent.  But if you have any specific
questions about them, I'd be happy to explain things.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".