Opened 10 years ago

Closed 10 years ago

#8361 closed Bugs (fixed)

Linking problems with MSVC

Reported by: Andrey Semashev Owned by: Hartmut Kaiser
Milestone: To Be Determined Component: spirit
Version: Boost 1.53.0 Severity: Problem
Keywords: Cc:

Description

I've been reported a linking issue with MSVC 8 when Boost.Spirit.Karma is used in several translation units of a static library. Apparently, the problem is with some static asserts that generate conflicting symbols in the library.

Looking at the boost/spirit/home/support/assert_msg.hpp file and the FAQ, it seems this is a known problem, and defining BOOST_SPIRIT_DONT_USE_MPL_ASSERT_MSG=1 should work around this issue. However, this macro is not defined anywhere in the code which means the user has to discover this problem himself and then look for the solution. It would be better if the library defined the macro automatically for the compilers that are known to be affected by this problem (at least, MSVC 8 for now).

As a side note, it might be worthwhile to use BOOST_STATIC_ASSERT_MSG instead of either BOOST_STATIC_ASSERT or BOOST_MPL_ASSERT_MSG whenever static_assert is supported by the compiler.

Attachments (1)

assert_msg.hpp.patch (1.2 KB ) - added by Andrey Semashev 10 years ago.
The patch automatically enables the linking problem workaround and uses static_assret when possible.

Download all attachments as: .zip

Change History (5)

comment:1 by Joel de Guzman, 10 years ago

Owner: changed from Joel de Guzman to Hartmut Kaiser

comment:2 by Hartmut Kaiser, 10 years ago

Do you mind submitting a patch solving this issue? I'd be glad to accept it.

by Andrey Semashev, 10 years ago

Attachment: assert_msg.hpp.patch added

The patch automatically enables the linking problem workaround and uses static_assret when possible.

comment:3 by Andrey Semashev, 10 years ago

Sorry, I didn't have the chance to verify this patch as I don't have access to MSVC now.

One additional note. The patch uses static_assert when BOOST_NO_CXX11_STATIC_ASSERT is not defined, and there seems to be no way to print Types argument into the error message. Due to the way the macro is used, this argument will probably be visible somewhere in the error message backtrace, so I figured there is no need to embed it into the message as well. But you may think otherwise.

comment:4 by Hartmut Kaiser, 10 years ago

Resolution: fixed
Status: newclosed

(In [83738]) Spirit: fix #8361: Linking problems with MSVC

Note: See TracTickets for help on using tickets.