Boost C++ Libraries: Ticket #6779: Scoped enums break linking compatibility between C++98 and C++11

Andrey Semashev — Mon, 01 Apr 2013 09:06:02 GMT

Any news on this problem? It still persists in 1.53.

anonymous — Fri, 10 May 2013 21:14:48 GMT

Indeed.

viboes — Fri, 10 May 2013 21:38:20 GMT

I don't understand. Are you suggesting that boost libraries can not use any C++11 specific feature on their interface when compiling with a C++11 compiler?

Andrey Semashev — Fri, 10 May 2013 21:43:21 GMT

Replying to viboes:

I don't understand. Are you suggesting that boost libraries can not use any C++11 specific feature on their interface when compiling with a C++11 compiler?

Yes, at least when the platform has different ABI for C++03 and C++11 for that feature.

viboes — Sat, 11 May 2013 06:36:21 GMT

Replying to andysem:

Replying to viboes:

I don't understand. Are you suggesting that boost libraries can not use any C++11 specific feature on their interface when compiling with a C++11 compiler?

Yes, at least when the platform has different ABI for C++03 and C++11 for that feature.

It would be worth sharing on the ML the list the features that are in the same case. Behind scoped enums, which others fall in this cathegory?

Andrey Semashev — Mon, 13 May 2013 11:35:45 GMT

Replying to viboes:

It would be worth sharing on the ML the list the features that are in the same case. Behind scoped enums, which others fall in this cathegory?

I don't have a complete list of C++11 features that break the ABI. But I presume any C++11-specific feature that affects types and function signatures should be avoided in binary interfaces. This includes scoped enums and rvalue references at the very least. noexcept doesn't affect function signatures, so it should be safe. constexpr should be inline, so it should not pose any problems, too.

Also one should be very careful with STL types that are present in binary interfaces. Obviously, if std::tuple is present in a function signature, then this function cannot be called from a C++03 program. There may be less obvious examples, such as container iterator types, if they are different for C++03 and C++11.

chrisstankevitz@… — Fri, 06 Sep 2013 22:17:02 GMT

It seems boost::signals2 is also affected by this. Consider this function definition:

void f(boost::signals2::signal<void(const std::string&)>::slot_type)

c++98 signature: f(boost::signals2::slot1<void, std::string const&)

c++0x signature: f(boost::signals2::slot<void (std::string const&))

Andrey Semashev — Sat, 07 Sep 2013 17:27:46 GMT

Boost.Signals2 does not have a compiled binary, so this is localized to the user's code. In general Boost libraries don't guarantee ABI stability for different compiler configurations. The problem with Boost.Filesystem is a special case because it has a compiled binary, which is supplied by OS distribution vendors.

ippattume@… — Thu, 19 Dec 2013 12:50:56 GMT

I've had no problem with boost 1.55 until today's update to 1.55.0-3. I've had to downgrade to 1.55.0-2 to make my project link correctly.

status, milestone changed; resolution set

Beman Dawes — Fri, 24 Oct 2014 16:02:25 GMT

status new → closed
resolution → fixed
milestone To Be Determined → Boost 1.57.0

#6124, #6779, and #10038 are all the same problem. The private library interface has been changed to use a plain-old C++03 enum. This is the fix suggested by Andy in 6779.

The fix was too late for 1.57 beta 1, but should be in the final 1.57 release.

Thanks for your patience,

--Beman

daira@… — Fri, 09 Jan 2015 23:25:43 GMT

I am still getting this error even though I have tried building against boost 1.54 and 1.57. I have to compile using C++11. Is there any other known workaround?

Andrey Semashev — Sat, 10 Jan 2015 00:07:22 GMT

Replying to daira@…:

I am still getting this error even though I have tried building against boost 1.54 and 1.57. I have to compile using C++11. Is there any other known workaround?

Feel free to reopen the ticket with the error you get for 1.57.

daira@… — Sat, 10 Jan 2015 03:52:08 GMT

Replying to andysem:

Feel free to reopen the ticket with the error you get for 1.57.

False alarm; due to a build system problem, I was actually compiling against a different version of boost than I thought. It does seem to be fixed with 1.57.