I've decided to have a go at fixing module support on Windows platforms.
I've reluctanly set up my home machine to dual-boot Windows and Linux,
and have installed cygwin on the Windows side. I came up with a test to
see if I correctly understand the linking problems involved. It didn't
work out quite as I expected, though, and I wonder if anybody can give
me a boost in the right direction.
The test.c file is supposed to be an analog of XEmacs: it is
self-contained, has a function that can be used by modules, and opens
and attempts to use some user-specified DLL. On the other hand, dll.c
is the source for a simple dll.c that provides a function needed by
test.c, and uses a support function provided by test.c. The Makefile
attempts to compile these to an executable, test.exe, and a DLL, my.dll.
With the Makefile as given, the result is:
$ ./test.exe my.dll "This is a test"
Unable to open library my.dll
If the use of dlltool is removed in favor of the two commented lines
below it, namely:
gcc -o junk -shared -Wl,--out-implib -Wl,libtest.a test.o
then the result is:
$ ./test my.dll "This is a test"
The string is This is a test
Its reverse is tset a si sihT
Also, I note that when gcc is used to create junk.exe as above, it says
"Creating library file: libtest.a", but dlltool does not. When the
"-shared" is omitted from the gcc line above, to create the actual
test.exe executable, then libtest.a is NOT created. And finally, the
junk.exe created above really is junk: it is actually a DLL, not an
executable. I'd rather not create a junk XEmacs DLL just to get the
import library. Can anybody show me how to use dlltool appropriately to
make this work?