Status of libtool 2.2.X?

[Kevin Kofler]

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