Re: [Mingw-users] problems when creating Windows DLL using mingw

[LRN <lr...@gm...>]

On 17.01.2010 17:38, Vincent Torri wrote:
>
>
> On Sun, 17 Jan 2010, LRN wrote:
>
>> On 17.01.2010 15:28, Vincent Torri wrote:
>>>
>>>
>>> On Sun, 17 Jan 2010, LRN wrote:
>>>
>>>> On 17.01.2010 14:54, Vincent Torri wrote:
>>>>>
>>>>> On Sun, 17 Jan 2010, LRN wrote:
>>>>>> I prefer to create a special lib*.la in lib subdirectory instead.
>>>>>> Did
>>>>>> that for libdxgui.a (which doesn't have a corresponding .dll) and it
>>>>>> worked just fine. The secret is to have dlname='' and both
>>>>>> library_names
>>>>>> and old_library = 'lib*.a' (not .dll.a)
>>>>>>
>>>>> i don't need to do such hack to make libtool working with winsock2.
>>>>> Updrage libtool, verifiy that libtool is aware of dll built,
>>>>> no-undefined
>>>>> must be passed to libtool ldflags variable (that is already done
>>>>> by the
>>>>> OP) ; it should be sufficient.
>>>>>
>>>> For winsock2 - yes, because you have actual ws2_32.dll in your
>>>> system32
>>>> subdirectory (and myself, i never had any problems in linking with
>>>> -lws2_32). But for some other libraries (such as the ones that i've
>>>> named) that might not be sufficient.
>>>
>>> it's not a problem of having or not a dll. It's a problem of libtool
>>> not doing correctly its job. For example : libiberty.a. I have no
>>> problem when i pass -liberty during the link.
>>>
>> Are you linking -liberty to an executable or to a library?
>
> a library.
>
Then why am i getting
*** Warning: linker path does not have real file for library -liberty.
*** 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 libiberty and none of the candidates passed a file format test
*** using a file magic. Last file checked: /mingw/lib/libiberty.a
and you don't? :-\
> Vincent Torri