Daniel P. Berrange <berrange <at> redhat.com> writes:
> Traditionally the problem has been that you actually need to generate two
> different bits of the DLL. A runtime part and linktime part.
MinGW can actually link a DLL directly these days. However, that feature is
rarely used in practice for a few reasons:
* Linking a DLL directly means you need to have it - this eliminates the native
Window$ DLLs for cross-compiling, so I expect w32api to keep coming with import
libraries for the foreseeable future.
* M$VC doesn't support it, so projects wanting to also support M$VC also have
to support import libraries anyway (even if there's the added complexity that
an import library for one compiler doesn't work with the other, one has to
generate them both from the .def file, or use some convoluted process to
convert one to the other (basically, reverse-engineering a .def first and then
building the other import library from that) - that's why you see libraries
coming with both a .lib and a .a import library: .lib is for M$VC, .a for
MinGW).
* The usual layout for Free Software libraries on Window$ (at least all the
major ones I've seen: GNUWIN32 packages, GTK+ packages, KDE 4 packages) has the
DLLs in bin so they're found by the executables also in bin without search path
tweaking, but the linker won't look in bin for libraries (unless you use a -L
switch, and libraries are not set up to do that with a bin directory), so
having the import library in lib is helpful.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
