Re: Win32 libltdl issue

[Charles Wilson]

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