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
Subject: RE: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-class: urn:content-classes:message
Date: Tue, 26 Oct 2004 10:08:49 +0200
Message-ID: <90459864DAD67D43BDD3D517DEFC2F7D723C@axon.Axentia.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
From: "Peter Ekberg" <peda AT axentia DOT se>
To: <cygwin AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id i9Q88wl7021062

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/