libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool woes


From: Ozkan Sezer
Subject: Re: libtool woes
Date: Tue, 10 Sep 2013 09:09:26 +0300

On 9/10/13, JonY <address@hidden> wrote:
> On 9/10/2013 02:12, Ozkan Sezer wrote:
>>
>> *** Warning: linker path does not have real file for library -lole32.
>> *** 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 libole32 but no candidates were found. (...for file magic test)
>>
>> *** Warning: linker path does not have real file for library -ldsound.
>> *** 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 libdsound but no candidates were found. (...for file magic test)
>>
>> *** Warning: linker path does not have real file for library -lwinmm.
>> *** 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 libwinmm but no candidates were found. (...for file magic test)
>> *** The inter-library dependencies that have been dropped here will be
>> *** automatically added whenever a program is linked with this library
>> *** or is declared to -dlopen it.
>>
>> I am stuck with this. Can anyone see what I am doing wrong?
>>
>
> This needs to be taken up with the libtool developers.
>
> libtool is technically correct, but libole32.a is a mixed shared lib
> with static data inserted.

The thing is, libole32.a is _not_ mixed: it is generated only from
ole32.def.  My first thought was like yours when I first hit the issue with
libws2_32.a, which _is_ mixed, but then saw it with others which are
let's say _pure_

>
> libtool should use dlltool --identify when available.
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]