id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
1058	Cygwin libraries & GNU libtool	mike@…	Vladimir Prus	"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.
"	Support Requests	closed	To Be Determined	build	Boost 1.34.0	Problem	fixed	Cygwin libtool shared dll