On 8 March 2010 03:21, Vladimir Prus <vladimir@codesourcery.com> wrote:

Paul wrote:

...

Hi all,

I'm confused about boost dynamic linking on windows MSVC90

I always define: BOOST_ALL_NO_LIB So that I directly control which DLLs I link to. I add the signals dll for linking.

Then, if I define BOOST_ALL_DYN_LINK, I get lots of these messages:

boost_1_42_0\boost/signals/detail/signal_base.hpp(113) : warning C4251: 'boost::signals::detail::signal_base_impl::combiner_' : class 'boost::any' needs to have dll-interface to be used by clients of class 'boost::signals::detail::signal_base_impl' 39> boost_1_42_0\boost/any.hpp(36) : see declaration of 'boost::any'

I've read up on this and understand why the warnings are shown.

BUT, I don't understand why I am able to still link my program if I do NOT define BOOST_ALL_DYN_LINK.

Without the flag, it compiles without warnings, it links without problems, AND the executable requires the signals DLL to be available, so clearly it IS dynamically linked. Right?

Do you include import library for Boost.Signals in the link? Then, presumably, compiler automatically 'dllimports' the symbol. Please see:

http://blogs.msdn.com/oldnewthing/archive/2006/07/26/679044.aspx

Does this help?

- Volodya

This DOES help a lot ! So, I have a few options: 1) Define BOOST_ALL_DYN_LINK and put up with the excess warnings. This would be ok if the boost developers could "fix" their headers by adding #pragmas to hide the warnings when they know its not a problem. 2) Define BOOST_ALL_DYN_LINK and write a couple of header files that wrap the boost headers with #pragmas (eg especially for boost::signals) 3) Do not define BOOST_ALL_DYN_LINK, and allow Windows the link "the naive way", which might give slower performance, but maybe not. Thanks Volodya !

On Mon, Mar 8, 2010 at 9:43 AM, Vladimir Prus <ghost@cs.msu.su> wrote:

Paul wrote:

...

    > Then, if I define BOOST_ALL_DYN_LINK, I get lots of these messages:     >     > boost_1_42_0\boost/signals/detail/signal_base.hpp(113) : warning    C4251:     > 'boost::signals::detail::signal_base_impl::combiner_' : class    'boost::any'     > needs to have dll-interface to be used by clients of class     > 'boost::signals::detail::signal_base_impl'     > 39>        boost_1_42_0\boost/any.hpp(36) : see declaration of    'boost::any'     >     > I've read up on this and understand why the warnings are shown.     >     > BUT,     > I don't understand why I am able to still link my program if I do    NOT define     > BOOST_ALL_DYN_LINK.     >     > Without the flag, it compiles without warnings, it links without    problems,     > AND the executable requires the signals DLL to be available, so    clearly it     > IS dynamically linked.  Right?

   Do you include import library for Boost.Signals in the link? Then,    presumably,    compiler automatically 'dllimports' the symbol. Please see:

          http://blogs.msdn.com/oldnewthing/archive/2006/07/26/679044.aspx

   Does this help?

   - Volodya

This DOES help a lot !

So, I have a few options:

1) Define BOOST_ALL_DYN_LINK and put up with the excess warnings.   This would be ok if the boost developers could "fix" their headers by adding #pragmas to hide the warnings when they know its not a problem.

2) Define BOOST_ALL_DYN_LINK and write a couple of header files that wrap the boost headers with #pragmas (eg especially for boost::signals)

3) Do not define BOOST_ALL_DYN_LINK, and allow Windows the link "the naive way", which might give slower performance, but maybe not.

It would certainly help if somebody with practical experience with Windows comment here (which I am not). For all I understand, that warning is false positive, given that boost::any is all templated code, and probably the best solution is to disable it in your project settings -- and, maybe, when building boost itself? Comments?

If is a false positive, ignore it. That could only cause problems if boost::any changed between boost versions *AND* you compiled multiple dynamic libraries with different boost versions where boost::any changed *AND* you passed a boost::any across the library boundaries *AND* used it on both sides rather then just pass it back. Since that is unlikely to be the case, ignore it.