Howard Chu wrote:
One other annoying gotcha when building with libtool and Win32 is that libtool (at least in the 1.x line) assumed that any lib*.a was a static library, and refused to link it into a DLL. It didn't account for the possibility that the library was actually a DLL import library. Now that the linker can automatically Do The Right thing regardless of what type of library is fed to it, libtool could just use pass_all here. So again, it simplifies the Win32 support if you can assume a recent toolchain.
Right now (1.x), when libtool sees that you're trying to link against a DLL, it calls dlltool to generate a new import library on the fly, and then deletes it when that step completes. It does this each time the DLL is referenced in a build procedure, which is a ton of wasted effort and makes builds much slower than they should be. With a new toolchain you could delete all of the commands for these cases and just let ld link the thing.
Huh? What are you talking about? From ltmain.in, 1.5.10:
This is the function that should be called to ID a dependency (note: no reliance on filename at all).
Sorry, I was looking at 1.4.3, which is nowhere near as sophisticated as that. Still the point remains, there's a fair chunk of processing here to determine some things that the linker now handles transparently.
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
