Cygwin libraries & GNU libtool

[mike@…]

I'm using Cygwin on Windows XP with Boost 1.34.0 + the patches from these two tickets applied:

​http://svn.boost.org/trac/boost/ticket/966 ​http://svn.boost.org/trac/boost/ticket/1025

The build and install stages seem to work correctly now, but now when I try to link in Boost libraries with my own shared library, GNU libtool (1.5.23a) is giving me errors about not being able to find the "real filenames" and refuses to build DLLs (it only builds shared libraries which is a problem for me since I'm building plug-ins):

/bin/sh ../libtool --tag=CXX --mode=link g++ -DLIBPION -ggdb -Wall -no-undefined -release 0.1.7 -mthreads -L/opt/build/boost-1.34.0/lib -o libpion.la -rpath /usr/local/libpion-0.1.7/lib PionPlugin.lo PionEngine.lo TCPServer.lo HTTPTypes.lo HTTPResponse.lo HTTPRequestParser.lo HTTPServer.lo -lboost_thread-mt -lboost_system-mt -lboost_filesystem-mt -lws2_32 -lmswsock

* Warning: linker path does not have real file for library -lboost_thread-mt. * 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 libboost_thread-mt but no candidates were found. (...for file magic test) ...

The import library names are currently using the format "boost_*.dll.a" while libtool expects libraries to have the standard "lib" prefix. Adding the "lib" prefix seems to fix this problem. Note that previous Boost releases (namely 1.33.1) used the format that is compatible with libtool -- 1.34.0 seems to have broken compatibility.

[Vladimir Prus]

Let me clarify. Are you saying that in 1.33.1, import libraries on cygwin were named libboost_XXX.dll.a, and in 1.34 they are named boost_XXX.dll.a, and that, in particular, confuses libtool?

[anonymous]

Yes.

Since the *.dll.a files do not have a "lib" prefix, libtool in cygwin does not recognize them and will only link with the static libs. This is especially a problem if you're trying to use libtool to build a DLL that is linked with the boost DLLs.

It could be a problem with libtool or just me not knowing about certain options I should be passing to it (I'm fairly new to autotools), but in 1.33.1 the libraries had a "lib" prefix and therefore this was not a problem.

Thanks, -Mike

[Roland Schwarz]

We need more input.

The following code snippet, is not able to reproduce the described behavior, although not the first hint of a library being present. Try this (in an empty dir):

libtool --mode=link g++ -no-undefined -o libbaz.la -L. -lfoobar

On the other hand I verified, that the gnu linker ld is able to accept xxx.dll.a or libxxx.dll.a as import libraries.

I am pretty sure libtool also will find xxx.lib named import libraries.

I guess the reported bug is not related to boost naming scheme at all, but this is just a guess. It would be ideal if the described behavior would be presented in a stripped down version, since we have no access to the posters prerequisites (i.e pion libs)

Roland aka speedsnail

[Mike]

The problem is not the SUFFIX but the PREFIX. In 1.33.x, the libraries included the prefix "lib". In 1.34.0 this prefix was removed. Without the "lib" prefix (i.e. "boost_thread_" versus "libboost_thread_"), libtool cannot seem to find the library.

[anonymous]

There were actually two versions:

1) libxxx.lib and 2) xxx.lib

1) is the static version and 2) is the import lib for the DLL. This scheme has been restored on trunk. Could you please check if this works with the trunk version? If yes this can be merged back as a bug-fix for 1.34.

Thank you.

[Mike]

I just confirmed that the latest code in trunk (1.35) works great with libtool again. Thanks! -Mike

P.S. the project I was referring to (libpion) is open source code at ​http://www.atomiclabs.com/libpion/ just in case anyone else needs to test.