Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Message-ID:	<417D211A.2080905@x-ray.at>
Date:	Mon, 25 Oct 2004 17:51:54 +0200
From:	Reini Urban <rurban AT x-ray DOT at>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8a3) Gecko/20040817
MIME-Version:	1.0
To:	Peter Ekberg <peda AT axentia DOT se>
CC:	cygwin AT cygwin DOT com
Subject:	Re: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
References:	<90459864DAD67D43BDD3D517DEFC2F7D7239 AT axon DOT Axentia DOT local>
In-Reply-To:	<90459864DAD67D43BDD3D517DEFC2F7D7239@axon.Axentia.local>
X-IsSubscribed:	yes

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?

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

> If I change to
> deplibs_check_method="file_magic"
> it works.

because it overrides the check. it passes no args to the func.
-- 
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/

- Raw text -