Scoped enums break linking compatibility between C++98 and C++11

[Andrey Semashev]

The compiled part of Boost.FileSystem v3 uses scoped enums in its interface. This is the case with the copy_file function. This creates linking incompatibilities if Boost is compiled in C++98 and user's code in C++11 mode because in the former case scoped enums are emulated and thus generate a different name in the decorated function names. It's worth noting that typically binary distributions of Boost in Linux are built in C++98 mode, which complicates linking C++11 user's code.

The suggested fix is to use either integers or traditional enums in the private library interface.

[Andrey Semashev]

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

[anonymous]

Indeed.

[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?

[Andrey Semashev]

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]

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]

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@…]

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]

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@…]

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.

[Beman Dawes]

#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@…]

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]

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@…]

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.