Opened 7 years ago

Closed 4 years ago

Last modified 4 years ago

#6779 closed Bugs (fixed)

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

Reported by: Andrey Semashev Owned by: Beman Dawes
Milestone: Boost 1.57.0 Component: filesystem
Version: Boost 1.48.0 Severity: Problem
Keywords: Cc:

Description

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.

Change History (13)

comment:1 Changed 6 years ago by Andrey Semashev

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

comment:2 Changed 6 years ago by anonymous

Indeed.

comment:3 Changed 6 years ago by 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?

comment:4 in reply to:  3 ; Changed 6 years ago by 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.

Last edited 6 years ago by Andrey Semashev (previous) (diff)

comment:5 in reply to:  4 ; Changed 6 years ago by 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?

comment:6 in reply to:  5 Changed 6 years ago by 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.

comment:7 Changed 5 years ago by 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&))

comment:8 Changed 5 years ago by 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.

comment:9 Changed 5 years ago by 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.

comment:10 Changed 4 years ago by Beman Dawes

Milestone: To Be DeterminedBoost 1.57.0
Resolution: fixed
Status: newclosed

#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

comment:11 Changed 4 years ago by 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?

comment:12 in reply to:  11 ; Changed 4 years ago by 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.

comment:13 in reply to:  12 Changed 4 years ago by 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.

Note: See TracTickets for help on using tickets.