> -----Ursprüngliche Nachricht-----
> Von: cygwin-owner@sources.redhat.com
> [mailto:cygwin-owner@sources.redhat.com]Im Auftrag von David Westbury
> Gesendet am: Donnerstag, 15. November 2001 17:11
> An: cygwin@cygwin.com
> Betreff: Linking to commercial dll's
>
> I'm attempting to link a C program that I've written to a commercial dll
> (non-MS) using gcc in cygwin. I've read about everything I can find about
> dll's but I can't seem to make my program access functions in the dll
> correctly. My program compiles/links without errors using gcc, and even
> runs correctly to some extent. Some functions work, others don't. The
> functions that don't work seem to corrupt memory as evidenced by changes in
> random variable values. This occurs even when the function return status
> indicates success. The commercial package provides a ".dll" file, a ".lib"
> file, and a ".h" file. These are obviously intended for use in a Windows
> programming environment. I would appreciate if someone knowledgable would
> tell me what steps would typically be required to link a program to a well
> established commercial dll. For example, what might a typical gcc string
> look like? Do gcc switches like "-L", and "-l" apply? Should I be linking
> to the .dll or the .lib file?
>
> Dll's seem to be an especially difficult subject in cygwin, requiring
> detailed knowlege of the MS way of doing things. Are dll's not
> standardized? Is a "cookbook" approach to dll linking not possible? The
> issue seems to be a steep hill for an average working programmer, like me,
> to climb. This limits the usefulness of cygwin as a programming environment
> for me.
>
> BTW, is cygwin intended for MS programmers wanting to explore the Unix
> world or is it of more interest to Unix programmers who, like me, have an
> occasional need to run Unix programs on Windows?  Programmers coming from
> Unix typically won't know much about dll's so a little more introductory
> documentation or pointers to such material would seem appropriate for the
> cygwin site. I've been to the bookstores and haven't found much help there,
> even in Windows programming texts. Apparently dll's simply work correctly
> in Windows and require little explanation. One text did say something that
> seemed to indicate that I should be linking against the .lib file as it
> contains pointers into the .dll fine. This doesn't work for me at all
> however.
>
> Here's the gcc string I'm using that results in a partially working
> executable:
>
> gcc -g myprog.c  -o myprog  /<path to commercial dll>/filename.dll
>
> Any help or pointers to information would be greatly appreciated.
>
1. For a deeply explanation of the windows dll format look at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwbgen/html/ms
dn_peeringpe.asp.

2. You have to create a ld compatible import library. You can use the tools
impgen and dlltool for doing this. impgen comes from the libtool package and is
appended to this mail. dlltool is a part of the basic cygwin.

Here is an example for a dll named 'libxslt.dll':

1. compile the tool impgen with the appended source file

	gcc -o impgen impgen.c
	cp ./impgen /usr/local/bin


2. create a file with all exported symbols from the dll (it's called 'def'
file).

	impgen libxslt.dll >libxslt.def


3. create an import library with this def file

	dlltool -d libxslt.def -l libxslt.a


4. Now you can link your app with the dll (in truth with the import library)
	Note:
	There may be some compiling problems with
	the include file from your dll in case of
	redefined symbols or compiler syntay.
	It may be nessesary to patch this.

	gcc -o yourapp yourapp.c -L. -lxslt

	Note2:
	You can verify using the import library with the -Wl,--verbose flag in you
command line.

	gcc -o yourapp yourapp.c -L. -lxslt -Wl,--verbose

	Then you see some lines with

	...
	attempt to open /usr/lib/w32api/libkernel32.dll.a failed
	attempt to open /usr/lib/w32api/libkernel32.a succeeded
	...

	which shows, that you are linking the .a file, not the dll.


Perhaps that helps

PS: To the cygwin cracks: If I have written something wrong, please correct
this.

Regards

Ralf Habacker