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:
func_win32_libid () {
win32_libid_type="unknown"
win32_fileres=`file -L $1 2>/dev/null`
case $win32_fileres in
*ar\ archive\ import\ library*) # definitely import
win32_libid_type="x86 archive import"
;;
*ar\ archive*) # could be an import, or static
if eval $OBJDUMP -f $1 | $SED -e '10q' 2>/dev/null | \
$EGREP -e 'file format pe-i386(.*architecture: i386)?' >/dev/null ; then
win32_nmres=`eval $NM -f posix -A $1 | \
sed -n -e '1,100{/ I /{x;/import/!{s/^/import/;h;p;};x;};}'`
if test "X$win32_nmres" = "Ximport" ; then
win32_libid_type="x86 archive import"
else
win32_libid_type="x86 archive static"
fi
fi
;;
*DLL*)
win32_libid_type="x86 DLL"
;;
*executable*) # but shell scripts are "executable" too...
case $win32_fileres in
*MS\ Windows\ PE\ Intel*)
win32_libid_type="x86 DLL"
;;
esac
;;
esac
$echo $win32_libid_type
}
This is the function that should be called to ID a dependency (note: no reliance on filename at all).
-- Chuck
