From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-03-09 00:55:29
On Friday 09 March 2007 08:45, David Abrahams wrote:
> As Boost moves to v2 of its build system, we have removed the
> capability to tell gcc to generate import libraries, instead
> attempting to use the same dynamic linking paradigms used by GCC on
> linux. Why use different logic on Cygwin, after all?
> This has caused problems for Boost.Python, which has to be able to
> generate dynamically-loaded Python extension modules that link to the
> Boost.Python shared library, libboost_python.dll. As far as I can
> tell, Cygwin's simulation of the linux ability to link without implibs
> is not entirely transparent, since any inline function used by both
> libboost_python.dll and the Python extension modules will cause a
> multiple-definition error at link time.
> Can some Cygwin person confirm that this is the behavior you'd expect
> when linking two DLLs together, each of which contains an
> instantiation of a particular inline function? Can you offer a
> workaround that doesn't involve import libraries (I'm willing to
> generate one; I just want to know)?
> For the Boost.Build people, IMO even if there's a workaround, the
> ability to generate implibs has to be restored before we ship, as it's
> a crucial function of BBv1 (and some people are surely using it in the
> mingw configuration of gcc, if not the cygwin one).
One good point I've heard is that at least for mingw, not using import
libraries means a library created with mingw cannot be used by msvc
projects. I think that's good enough point that we ought to add
import libraries generation for mingw.
And probably, mingw import lib support will automatically add this
support for cygwin. I can look into this, if you want.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk