I have one problem with libtool 1.9d, that I suspect is still present in 1.9f. If I specify -lpthread when linking, libtool searches for a real file matching -lpthread, like this:
*** Warning: linker path does not have real file for library -lpthread. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libpthread and none of the candidates passed a file format test *** using a file magic. Last file checked: /lib/libpthread.a
Then you have a binutils problem. The new magic for /lib/libpthread.a tells libtool that this is the import library. (which normally would be called libpthread.dll.a)
$ file -L /lib/libpthread.a /lib/libpthread.a: current ar archive
# ok, this failed.
$ objdump -f /lib/libpthread.a | sed 10q
#this will detect together with nm that it is an import lib
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
;;
....
Because of this, libtool fails to build the dll in question, which is a pity.
-- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/