This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Cygwin 1.1.4: DLL development problems, test case included.


Hello all,

I encountered some runtime problems in building DLLs under 1.1.4.  After
checking out the archives of this list, I managed to get simple cases to
build and run, but quickly discovered other problems.  The following is the
first part of the README me file from a test case I put together.  The full
README contains some "cygcheck" output as well.  I've attached the test case
(as a gzipped tar file), but I don't know if it will go through.  If it
doesn't please contact me for a copy.

Thanks.

-- Jim Mayer

---------------------

Here is a pair of dummy applications that exercise DLL building in the
cygwin 1.1.4 environment.  If I did this right, they expose a number of
bugs in the DLL handling code.

I've appended the output of "cygcheck -s -v -r" to the end of this note.

I'm running 1.1.4 with libcygwin.a updated by:

	http://sources.redhat.com/ml/cygwin/2000-08/msg00256/dll_entry.o

Thanks.

-- Jim Mayer (jmayer@crt.xerox.com)

---------------------------------------------

I use the following two recipies for building DLLs:

	gcc     -o libfubar.dll -shared \
		-Wl,--enable-auto-image-base \
		-Wl,--out-implib=libfubar.dll.a \
		-Wl,--output-def=libfubar.def \
		FUBAR_DLL/fubar.o \
		-lstdc++
and

	gcc     -o libfubar.dll -shared \
		-Wl,--enable-auto-image-base \
		-Wl,--out-implib=libfubar.dll.a \
		fixed-libfubar.def \
		FUBAR_DLL/fubar.o \
		-lstdc++

The first lets the linker build the ".def" file based on
"__declspec(dllimport)" and "__declspec(dllexport)" function and variable
attributes.  The second uses a hand made ".def" file.

I use some funky pre-processor stuff to make the DLL imports and exports
work right.  Check the front of the ".h" files.  I've run them through
the pre-processor and validated that the "__declspec" stuff is being
expanded appropriately.

Here are the files:

	Makefile		The entry point for running tests.
	Makefile.argle		A DLL (and test) that also uses
libfubar.dll.
	Makefile.fubar		A DLL and test program.
	README			This file.
	RESULTS			A directory containing the results I got
				from running the tests along with two
				stackdumps.  This is everything produced
				when I ran "make log."
	argle-test.cpp		A test program for libargle.dll.
	argle.cpp		The implementation of the "argle" class.
	argle.h			The definition of the "argle" class.
	fixed-libargle.def	A hand made ".def" file.
	fixed-libfubar.def	A hand made ".def" file.
	fubar-test.cpp		A test program for libfubar.dll
	fubar.cpp		The implementation of the "fubar" class.
	fubar.h			The definition of the "fubar" class.

If you run "make" with no arguments, you will get the following message:

	Valid targets are:
	    demo
	    handmade
	    bug1
	    bug2
	    handmade-bug2
	    bug3
	    handmade-bug3
	    clean -- the usual
	    distclean -- clean up everything
	    log -- run all of the tests create log files for them

Running any of the first 7 targets produces a short message and then
runs the test.  Here is a brief description of what the test does and
what results I get:

demo
	This builds the programs "test-fubar-lib.exe" and
	"test-fubar-dll.exe".  The two executables compute the same
	thing; the first is statically linked and the second uses a DLL.
	This test actually works.

	Note, however, that the ".def" files produced by the linker have
	far to o many symbols in them.	This, I think, causes problems in
	"bug3" (but that is speculation).

handmade
	The same as "demo", except that the hand made ".def" file is used.
	It still works.

bug1
	In trying to port a third party package to cygwin I ran into the
	following problem.  This package runs on most *nix systems and on
	Windows using Visual C++ version 6.  It uses __declspec(dllimport)
	and __declspec(dllexport), and got the same error messages that
	you see here.

bug2
	The "fubar" class contains a static instance of itself.  If I
	try to access that element from the test program I get a crash
	when using the DLL.

handmade-bug2
	This is the same test as "bug2" but with a hand made ".def" file.
	The test still fails.

bug3
	The "argle" class is a wrapper for the "fubar" class.  It also
	contains a static instance of itself.  When linked against both
	DLLs, the test application crashes.

handmade-bug3
	This is the same test as "bug3" but with two hand made ".def"
	files.	The test succeeds.

dllbug.tar.gz

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]