RE: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1

["Peter Ekberg" <peda at axentia dot se>]

Reini Urban wrote:
> Peter Ekberg schrieb:
>> Reini Urban wrote:
>>> Peter Ekberg schrieb:
>>> 
>>>> 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)
>> 
>> 
>> Actually I don't think I have problems with binutils, but thanks for
>> the useful pointer.
> 
> I think you do have. up-to-date?

Yes.

>> I have this in the generated libtool script:
>> --------------8<------------
>> # Method to check whether dependent libraries are shared objects.
>> deplibs_check_method="file_magic ^x86 archive import|^x86 DLL"
>> 
>> # Command to use when deplibs_check_method == "file_magic".
>> file_magic_cmd="func_win32_libid"
>> --------------8<------------
>> 
>> Is that what is expected?
> 
> yes, I posted the relevant snippet of this func_win32_libid function,
> so that you can check what's going on with your objdump and nm on
> your libpthread.a But you have a different/unsupported build so you
> should really step through your relevant func_win32_libid() function.

Ok, I pinpointed the problem. It wasn't a problem with binutils but
rather with configure.in. After a recent run of autoupdate it
contained:
_LT_SET_OPTION([disable-static])
_LT_SET_OPTION([dlopen])
_LT_SET_OPTION([win32-dll])
LT_INIT
(with some other stuff in between)

Changing that to
LT_INIT([disable-static dlopen win32-dll])
fixes the problem which was that $OBJDUMP was empty.

AC_CHECK_TOOL(OBJDUMP, objdump, false), among other things, wasn't
expanded without the above change in configure.in.

Thanks for the help, and sorry for the confusion.

(But I still think I have a point in that libtool should drop
 -lpthread just as it drops -lc and -lm. Why doesn't libtool
 drop -lpthread?)

Cheers,
Peter

--
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/