Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1444258 - clang-3.3 compile error with boost 1.53 signals
clang-3.3 compile error with boost 1.53 signals
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: boost (Show other bugs)
7.3
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Jonathan Wakely
qe-baseos-tools
:
Depends On: 999320
Blocks:
  Show dependency treegraph
 
Reported: 2017-04-20 21:23 EDT by Jos Collin
Modified: 2017-06-22 21:43 EDT (History)
9 users (show)

See Also:
Fixed In Version: 1.53.0-12.fc19
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 999320
Environment:
Last Closed: 2017-06-22 14:49:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jos Collin 2017-04-20 21:23:40 EDT
+++ This bug was initially created as a clone of Bug #999320. Somehow the fix didn't make it into RHEL7.
The bug is still present in the latest available version of boost-devel: 1.53.0-26. When applying the patch from https://svn.boost.org/trac/boost/ticket/8102 this issue disappears. +++

boost 1.53 (shipped with fedora 19) needs the patch (which is included in boost 1.54) from https://svn.boost.org/trac/boost/ticket/8102

when used with clang++ for compiling code using boost::signals2::signal

Othewise, compiling code like this fails:

  #include <boost/signals2/signal.hpp>
  int main()
  {
    boost::signals2::signal<void()> s;
    s();
  }

Compiled using 
  clang++ -c --std=c++11 

The boost patch is not needed for compiling using g++ (4.8.1).

Note:
g++     --version = g++ (GCC) 4.8.1 20130603 (Red Hat 4.8.1-1)
clang++ --version = clang version 3.3 (tags/RELEASE_33/rc3)

Compiler error:
In file included from test.cpp:1:
In file included from /usr/include/boost/signals2/signal.hpp:38:
In file included from /usr/include/boost/signals2/variadic_signal.hpp:21:
/usr/include/boost/signals2/detail/variadic_slot_invoker.hpp:89:16: error: no matching function for call to 'get'
          func(std::get<indices>(args)...);
               ^~~~~~~~~~~~~~~~~

--- Additional comment from Fedora Update System on 2013-08-21 10:46:07 EDT ---

boost-1.53.0-12.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/boost-1.53.0-12.fc19

--- Additional comment from Fedora Update System on 2013-08-21 20:45:19 EDT ---

Package boost-1.53.0-12.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing boost-1.53.0-12.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-15101/boost-1.53.0-12.fc19
then log in and leave karma (feedback).

--- Additional comment from Fedora Update System on 2013-08-24 18:30:28 EDT ---

boost-1.53.0-12.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 2 Jonathan Wakely 2017-04-21 06:58:24 EDT
(In reply to Jos Collin from comment #0)
> +++ This bug was initially created as a clone of Bug #999320. Somehow the
> fix didn't make it into RHEL7.

Because it never made it into boost-1.53.0-12.fc19 either.

> --- Additional comment from Fedora Update System on 2013-08-21 20:45:19 EDT
> ---
> 
> Package boost-1.53.0-12.fc19:
> * should fix your issue,

This was incorrect, 1.53.0-12 fixed the unrelated Bug 971956.
Comment 3 Jonathan Wakely 2017-04-21 07:22:13 EDT
(In reply to Jonathan Wakely from comment #2)
> > Package boost-1.53.0-12.fc19:
> > * should fix your issue,
> 
> This was incorrect, 1.53.0-12 fixed the unrelated Bug 971956.

Oh my mistake, I was looking at the 1.53.0-12 pkg on the f20 branch. You're right, that version was the fix for f19, sorry.
Comment 6 Jonathan Wakely 2017-04-24 11:00:23 EDT
I've done a bit more digging into the cause of the compiler error. Clang always identifies itself as GCC 4.2.1, which Boost 1.53 interprets to mean that no C++11 library features are supported. The <boost/config/stdlib/libstdcpp3.hpp> file has:

//  C++0x headers in GCC 4.3.0 and later
//
#if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 3) || !defined(__GXX_EXPERIMENTAL_CXX0X__)
#  define BOOST_NO_CXX11_HDR_ARRAY
#  define BOOST_NO_CXX11_HDR_REGEX
#  define BOOST_NO_CXX11_HDR_TUPLE
#  define BOOST_NO_CXX11_HDR_UNORDERED_MAP
#  define BOOST_NO_CXX11_HDR_UNORDERED_SET
#  define BOOST_NO_CXX11_HDR_FUNCTIONAL
#endif

In fact, clang is using the RHEL libstdc++ headers from GCC 4.8, which do support the <tuple> header. This misdetection will happen for any version of Clang, because they all identify as GCC 4.2.1 so get treated the same by the logic above.

Instead of fixing the misuse of std::get (as the F19 patch does) we could teach the Boost.Config header to be smarter about detecting C++11 features when compiling with Clang+libstdc++. The patch seems simpler and safer though.

A possible workaround for the customer is to modify the code like so:

#include <boost/config.hpp>
#if defined(__clang__) && __cplusplus >= 201103L
#  undef BOOST_NO_CXX11_HDR_TUPLE
#endif
#include <boost/signals2/signal.hpp>
int main()
{
  boost::signals2::signal<void()> s;
  s();
}

Note You need to log in before you can comment on or make changes to this bug.