[Mingw-users] dlltool with Boost C++ Libraries

[Nathan S. <re...@gm...>]

I'm trying to build a shared library (DLL) with the GNU autotools (including
libtool), with the target also linking to shared libraries from Boost.

The problem is that libtool can't find the "real file" for the shared library,
thus it pukes with the following warning:

*** Warning: linker path does not have real file for library
-lboost_system-mgw44-1_40.
*** 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_system-mgw44-1_40 and none of the candidates passed a file
format test
*** using a file magic. Last file checked:
/c/Boost/lib/libboost_system-mgw44-1_40.lib

*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module globalmsbot.  Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.

This can be attributed to the way the build solution for Boost works, described
here:

http://www.boost.org/doc/libs/1_40_0/more/getting_started/unix-variants.html#library-naming

Basically, the import libraries are prefixed with lib (e.g.:
libboost_system-mgw44-1_40.lib), while the shared library does not (e.g.:
boost_system-mgw44-1_40.dll).  They claim:

This convention distinguishes the static version of a Boost library from the
import library for an identically-configured Boost DLL, which would otherwise
have the same name.

Simply renaming the DLL won't solve the issue properly, as that would mean that
I would need to distribute the renamed files alongside my application (I
think...), thus defeating the whole purpose of a shared library (ignoring the
Windows shared library implementation argument at least).

How can I properly handle this, or can I?