[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14055: windows link problem with ".lib" files
From: |
Peter Rosin |
Subject: |
bug#14055: windows link problem with ".lib" files |
Date: |
Tue, 26 Mar 2013 17:17:17 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
On 2013-03-26 16:34, Andreas Otto wrote:
> Hi,
>
> in addition ...
>
> 1)
>
> my libtooll config -> attachment
>
> 2)
>
> $ sh ./libtool --features
> host: x86_64-w64-mingw32
> enable shared libraries
> disable static libraries
>
> 3)
>
> put the library with absolute path '/cygdrive/c/Tcl/lib/tcl86.lib' does not
> work ...
>
> + /bin/sh ../../libtool --tag=CC --verbose --mode=link /usr/bin/ccache
> x86_64-w64-mingw32-gcc -std=gnu99 -shared
> -I/home/dev1usr/Project/NHI1/theLink/tclmsgque/../libmsgque
> -I/cygdrive/c/Tcl/include -DMQ_IGNORE_EXTERN -g -Wall -Wcast-align -g -O2
> -shared -module -avoid-version -no-undefined /cygdrive/c/Tcl/lib/tcl86.lib -o
> tclmsgque.la -rpath /usr/local/lib/NHI1 tclmsgque_la-MqS_tcl.lo
> tclmsgque_la-misc_tcl.lo tclmsgque_la-msgque_tcl.lo tclmsgque_la-read_tcl.lo
> tclmsgque_la-send_tcl.lo tclmsgque_la-config_tcl.lo
> tclmsgque_la-service_tcl.lo tclmsgque_la-slave_tcl.lo
> tclmsgque_la-MqBufferS_tcl.lo tclmsgque_la-error_tcl.lo
> tclmsgque_la-link_tcl.lo tclmsgque_la-MqFactoryS_tcl.lo
> tclmsgque_la-MqDumpS_tcl.lo ../libmsgque/libtmp.la
> libtool: link: rm -fr .libs/tclmsgque.dll.a
> libtool: link: x86_64-w64-mingw32-gcc -std=gnu99 -shared
> .libs/tclmsgque_la-MqS_tcl.o .libs/tclmsgque_la-misc_tcl.o
> .libs/tclmsgque_la-msgque_tcl.o .libs/tclmsgque_la-read_tcl.o
> .libs/tclmsgque_la-send_tcl.o .libs/tclmsgque_la-config_tcl.o
> .libs/tclmsgque_la-service_tcl.o .libs/tclmsgque_la-slave_tcl.o
> .libs/tclmsgque_la-MqBufferS_tcl.o .libs/tclmsgque_la-error_tcl.o
> .libs/tclmsgque_la-link_tcl.o .libs/tclmsgque_la-MqFactoryS_tcl.o
> .libs/tclmsgque_la-MqDumpS_tcl.o -Wl,--whole-archive
> ../libmsgque/.libs/libtmp.a -Wl,--no-whole-archive -lws2_32 -O2 -o
> .libs/tclmsgque.dll -Wl,--enable-auto-image-base -Xlinker --out-implib
> -Xlinker .libs/tclmsgque.dll.a
> Creating library file: .libs/tclmsgque.dll.a.libs/tclmsgque_la-MqS_tcl.o: In
> function `Tclmsgque_ThreadExit':
> /home/dev1usr/Project/NHI1/theLink/tclmsgque/MqS_tcl.c:86: undefined
> reference to `__imp_Tcl_FinalizeThread'
> .libs/tclmsgque_la-MqS_tcl.o: In function `Tclmsgque_ProcessExit':
> /home/dev1usr/Project/NHI1/theLink/tclmsgque/MqS_tcl.c:78: undefined
> reference to `__imp_Tcl_Exit'
> .libs/tclmsgque_la-MqS_tcl.o: In function `Tclmsgque_MqS_Free':
> /home/dev1usr/Project/NHI1/theLink/tclmsgque/MqS_tcl.c:612: undefined
> reference to `__imp_TclFreeObj'
> .libs/tclmsgque_la-MqS_tcl.o: In function `Tclmsgque_MqS_Cmd':
> /home/dev1usr/Project/NHI1/theLink/tclmsgque/MqS_tcl.c:585: undefined
> reference to `__imp_Tcl_GetIndexFromObjStruct'
> /home/dev1usr/Project/NHI1/theLink/tclmsgque/MqS_tcl.c:581: undefined
> reference to `__imp_Tcl_WrongNumArgs'
> .libs/tclmsgque_la-MqS_tcl.o: In function `Tclmsgque_StorageDelete':
> /home/dev1usr/Project/NHI1/theLink/tclmsgque/MqS_tcl.c:148: undefined
> reference to `__imp_Tcl_GetWideIntFromObj'
> /home/dev1usr/Project/NHI1/theLink/tclmsgque/MqS_tcl.c:149: undefined
> reference to `__imp_Tcl_WrongNumArgs'
> /home/dev1usr/Project/NHI1/theLink/tclmsgque/MqS_tcl.c:148: undefined
> reference to `__imp_Tcl_WrongNumArgs'
> .libs/tclmsgque_la-MqS_tcl.o: In function `Tclmsgque_StorageSelect':
This is the classic case of putting the library before the objects.
As I told you before, you should have the library providing the
needed symbols *after* the objects requiring them. I.e.
/bin/sh ../../libtool --tag=CC --verbose --mode=link /usr/bin/ccache
x86_64-w64-mingw32-gcc -std=gnu99 -shared
-I/home/dev1usr/Project/NHI1/theLink/tclmsgque/../libmsgque
-I/cygdrive/c/Tcl/include -DMQ_IGNORE_EXTERN -g -Wall -Wcast-align -g -O2
-shared -module -avoid-version -no-undefined -o tclmsgque.la -rpath
/usr/local/lib/NHI1 tclmsgque_la-MqS_tcl.lo tclmsgque_la-misc_tcl.lo
tclmsgque_la-msgque_tcl.lo tclmsgque_la-read_tcl.lo tclmsgque_la-send_tcl.lo
tclmsgque_la-config_tcl.lo tclmsgque_la-service_tcl.lo
tclmsgque_la-slave_tcl.lo tclmsgque_la-MqBufferS_tcl.lo
tclmsgque_la-error_tcl.lo tclmsgque_la-link_tcl.lo
tclmsgque_la-MqFactoryS_tcl.lo tclmsgque_la-MqDumpS_tcl.lo
../libmsgque/libtmp.la /cygdrive/c/Tcl/lib/tcl86.lib
> I have to rename the library from 'C:\Tcl\lib\tcl86.lib' to
> 'C:\Tcl\lib\libtcl86.a' make the project compile-able
I can only assume, since the library is named tcl86.lib and not
libtcl86.dll.a, that it is was compiled with (and for) the
Microsoft Compiler. Since there is no standard for how libraries
are named in the land of Windows, there is no way for Libtool
to sanely catch all variations. Catching a new name might also
cause regressions for those that happen to have unfortunately
named files littering their file systems. Also, it's not always
safe to mix compilers (and runtimes), so sometimes it's better
to require user intervention to find libs from "the other side
of the fence".
> mfg AO
>
>
> Am 26.03.2013 15:05, schrieb Peter Rosin:
>> On 2013-03-26 10:38, Andreas Otto wrote:
>>> Hi,
>>>
>>> from time to time I use my automake/libtool project to build libraries on
>>> windows ...
>>> this create al least problems ...
>>>
>>> my actual problem is, I got a tcl distrubution from activestate providing a
>>> libraray:
>>>
>>> C:/Tcl/lib/tcl8.6.lib
>>>
>>> and using the libtool command:
>>>
>>> /bin/sh ../../libtool --tag=CC --mode=link /usr/bin/ccache
>>> x86_64-w64-mingw32-gcc -std=gnu99 -shared
>>> -I/home/dev1usr/Project/NHI1/theLink/tclmsgque/../libmsgque
>>> -IC:/Tcl/include -DMQ_IGNORE_EXTERN -g -Wall -Wcast-align -g -O2 -shared
>>> -module -avoid-version -no-undefined*-LC:/Tcl/lib -ltcl86* -o tclmsgque.la
>>> -rpath /usr/local/lib/NHI1 tclmsgque_la-MqS_tcl.lo
>>> tclmsgque_la-misc_tcl.lo tclmsgque_la-msgque_tcl.lo
>>> tclmsgque_la-read_tcl.lo tclmsgque_la-send_tcl.lo
>>> tclmsgque_la-config_tcl.lo tclmsgque_la-service_tcl.lo
>>> tclmsgque_la-slave_tcl.lo tclmsgque_la-MqBufferS_tcl.lo
>>> tclmsgque_la-error_tcl.lo tclmsgque_la-link_tcl.lo
>>> tclmsgque_la-MqFactoryS_tcl.lo tclmsgque_la-MqDumpS_tcl.lo
>>> ../libmsgque/libtmp.la
>>>
>>> with "*-LC:/Tcl/lib -ltcl86*" I got the mystic libtool error message that
>>> the library is NOT found ...
>> It would help if you quoted the error message.
>>
>>> using the "--debug" option give a hint ....
>> It would help if you shared the hint.
>>
>>> libtool does not serach for the "right" name ...
>>>
>>> If I copy the file tcl86.lib to libtcl86.a in the same directory ....
>>>
>>> => everything works fine.
>>>
>>> and now my question:
>>>
>>> why does "libtool" on "windows" does NOT search for "*.lib" files
>> I'll try to answer when you have provided the above details.
>>
>>> => enduser would be happy to save debugging hours ;-)
>>>
>>> Hint, I use the mingw cross compiler but this is NOT the problem.
>> Since you are using a cross compiler (presumably still from Cygwin),
>> you should not feed it Windows paths, you should feed it POSIX
>> paths. I.e. something like "-L/cygdrive/c/Tcl/lib -ltcl86". In addition
>> to that, you (or the package) have specified the library before any
>> object files, which is not the right thing to do. Try this:
>>
>> /bin/sh ../../libtool --tag=CC --mode=link /usr/bin/ccache
>> x86_64-w64-mingw32-gcc -std=gnu99 -shared
>> -I/home/dev1usr/Project/NHI1/theLink/tclmsgque/../libmsgque
>> -I/cygdrive/c/Tcl/include -DMQ_IGNORE_EXTERN -g -Wall -Wcast-align -g -O2
>> -shared -module -avoid-version -no-undefined -L/cygdrive/c/Tcl/lib -o
>> tclmsgque.la -rpath /usr/local/lib/NHI1 tclmsgque_la-MqS_tcl.lo
>> tclmsgque_la-misc_tcl.lo tclmsgque_la-msgque_tcl.lo
>> tclmsgque_la-read_tcl.lo tclmsgque_la-send_tcl.lo
>> tclmsgque_la-config_tcl.lo tclmsgque_la-service_tcl.lo
>> tclmsgque_la-slave_tcl.lo tclmsgque_la-MqBufferS_tcl.lo
>> tclmsgque_la-error_tcl.lo tclmsgque_la-link_tcl.lo
>> tclmsgque_la-MqFactoryS_tcl.lo tclmsgque_la-MqDumpS_tcl.lo
>> ../libmsgque/libtmp.la -ltcl86
>>
>> Cheers,
>> Peter
>>
>